The old calculation code failed to properly identify revs that
weren't tagged, leaving us with a version of "unknown" most of the
time during development.
Not yet used (will be enabled in a later patch).
This patch is a stripped down version of patches originally created by
Bryan O'Sullivan <bryano@fb.com>
This gcc option has been deprecated since at least 2009 (gcc 4.4),
and it causes compilations to fail entirely with gcc 4.6.x.
Upstream distutils bug: http://bugs.python.org/issue12641
This patch contains support for Plan 9 from Bell Labs. A README is
provided in contrib/plan9 which describes the port in greater detail.
A new extension is also provided named factotum which permits the
factotum(4) authentication agent to provide credentials for HTTP
repositories. This extension is also applicable to other POSIX
platforms which make use of Plan 9 from User Space (aka plan9ports).
Apparently, it prints nothing at all if the user installed only the
command-line tools. In that case, don't try to parse the empty output
-- just assume they have Xcode >= 4.
Merge the code from contrib/setup3.py in setup.
The argument for executing is marked as experimental.
Reason: The file in contrib was outdated (packages, cmdclass, ...)
If Python interpreter was built under Linux 3.x kernel, it reports
sys.platform to be 'linux3' (it is fixed for Python 3, but not for 2.x).
This cancels building inotify extension, which was built only for 'linux2'
platform. Improved test checks if sys.platform begins with 'linux', and together
with test for kernel version to be greater than 2.6 it seems to cover all known
cases.
It generates prebuilt index of all extensions, which will be used by
frozen exe when running 'hg help extensions'.
Now py2exe invokes this command automatically.
Fink's python is either i386 or amd64, but not universal. Setting ARCHFLAGS to the
empty string produces a successful build against both OS X python and fink python.
The modules will no longer be universal -- if that is an issue, we can change the
test to extract ARCHFLAGS from distutils.sysconfig and remove ppc if necessary.
This is revision a4229f13c374 of
http://py-nonblocking-http.googlecode.com/ with a no-check-code
comment added to the end of each file using `for fi in $(hg manifest |
grep mercurial/httpclient/) ; echo '# no-check-code' >> $fi`.
The previous test assumed that 'os.name' was "mac" on Mac OS X. This
is not the case; 'mac' was classic Mac OS, whereas Mac OS X has 'os.name'
be 'posix'.
Please note that this change will break Mercurial on hypothetical
non-Mac OS X deployments of Darwin.
Credit to Brodie Rao for thinking of CGSessionCopyCurrentDictionary()
and Kevin Bullock for testing.
Sometimes xcodebuild prints warnings to stderr, but runcmd() assumes anything
printed to stderr implies failure. Since runcmd() was originally only
intended to run hg, this was fine until it was pressed into service for
running xcodebuild. Thus: split runcmd() into two parts: runcmd(), which does
the minimal amount of work to run a subprocess, and runhg(), which calls
runcmd().
Add missing calls to close() to many places where files are
opened. Relying on reference counting to catch them soon-ish is not
portable and fails in environments with a proper GC, such as PyPy.
This provides two new features:
- Mercurial may be installed into a non-standard location without
having to set PYTHONPATH.
- Multiple installations can use Mercurial from different locations.
This patch adds access to util.h for the inotify C module by adding the
"mercurial" directory as an include dir, enabling access to the macros defined
in util.h.
In py3k, subprocess.Popen.communicate's output are bytes objects. String
literals are Unicode objects. Thus, when a bytes object startswith method is
called, with string literals, it fails. What this patch does is:
* Convert the string (unicode in py3k) literals to bytes objects;
* As "bytes" is not a builtin in python < 2.6, it defines a "b" helper
function that merely returns its argument, as suggested by Antoine Pitrou.
Windows python 2.4 os.stat() reports times including DST offset, while osutil.c
reports the correct value, which makes status() systematically compare files
content. This bug is fixed in python 2.5. Using osutil.py instead of osutil.c
is 4x times slower on large repositories but current code is completely
unusable. Given few people are likely to use python 2.4 on Windows this
solution was considered a good trade-off compared to more invasive solutions
trying to address the offset issue.
Fixes
warning: py2exe: Version Info will not be included:
could not parse version number ...
which was seen when doing nightly builds. hg.exe files
of nightly builds did not have any version info resoure,
which may cause problems with installers.
Also setting a copyright string for the version resource
(was missing).
Though we only support Python 2.4 or greater, we should keep setup.py
compatible with earlier versions on the syntactic level. Otherwise
people will simply get a SyntaxError when trying to install Mercurial
with an old version of Python. With this change, the setup.py file can
be imported with Python 2.3 and we then issue a friendly error message
when we detect that Python is too old.
Python will issue an ImportWarning when seeing 'import locale' if
there is a locale/ directory present without a __init__.py file.
The warning is silent by default, but it somehow shows up anyway on
Windows when setup.py executed hg. The warning causes runcmd to panic
since it sees output on stderr.
This patch ignores warnings on stderr about not importing a package.
Here is an array summarizing the mercurial version string:
[A] [B] [C] [D]
[1] clone tag clean => tag
[2] clone hash clean => latesttag+latesttagdistance-hash
[3] clone tag dirty => tag+date
[4] clone hash dirty => latesttag+latesttagdistance-hash+date
[5] archive tag clean => tag
[6] archive hash clean => latesttag+latesttagdistance-hash
Column [A]: Mercurial built from an hg *archive* or hg *clone* working directory
Column [B]: revision built has a *tag* or else default to the SHA1 *hash*
Column [C]: working tree *clean* or *dirty*
Column [D]: Mercurial version string
Over the previous version:
- row [5] did return just the node hash, now it returns the tag
- prepend the latest tag and the distance to it to rows [2][4][6]
- append also the date to row [3]; previously, it was just the tag
- the version string is with an empty string to avoid possible TypeError
exceptions during string manipulations
- factorize the function to run hg commands; remove the error message as it is
no more specific to the function.
This scheme enables to have first part of the version strings that can be
compared, whether it has been built from a tagged or untagged revision.
The second part of the version adds a hash for untagged revisions and today's
date if the working tree has local modifications.
As the version string does not contain spaces or special characters, it should
not break script parsing the 'hg version' command and should be usable for use
in file names.
The new code also ensure that the version string has exactly the same version
string, whether it has been built from an archive or from a clone.
The selection is somewhat arbitrary. In the case of the Zsh completion
file, it will not conflict with the builtin Zsh completions: they
are in a file named `_mercurial', not `_hg'.
Remove the `install_package_data' subclass of `install_data' and use
the `package_data' functionality provided by distutils instead. As
package data must be located within the package directory, the data
files are now generated in the build directory.
To simplify the functionality of this change, the top-level `doc' and
`templates' directories have been moved into the `mercurial' package
directory.
Previously, setup.py was enhanced to identify the Mercurial version
from either .hg/ or mercurial/__version__.py. When archives are
created using 'hg archive' or via hgweb, neither of those options are
available. However, there is a .hg_archival.txt file in the root of
the archive that has the information. This patch enhances setup.py to
identify the Mercurial version from the .hg_archival.txt file when
there is no .hg/ or mercurial/__version__.py available.
There is a problem with setup.py where it will not identify the Mercurial
version properly when not being ran in within a repository even if
mercurial/__version__.py exists.
To fix, use mercurial.__version__.version when available before defaulting
to "unknown". (Using mercurial.util.version() is not an option due to a
dependency issue where osutil can be referenced before it is built.)
- don't do version detection if there's no .hg directory
- shrink try: clause
- don't write __version__.py if version is unknown
(we might overwrite the real version)
This flag will make the build_py step install the pure Python modules
in mercurial/pure/ into mercurial/ and furthermore prevent building
the C extensions.
The target update-pot extracts strings using pygettext and updates the
i18n/hg.pot file. The translators can then use msgmerge to merge the
new strings in hg.pot with their xx.po file when they want to.
The setup.py file now includes files under both templates/ and i18n/
as data files.
- simplify version detection code
- move detection code into setup.py
- move version reading function into util.py
- drop version.py code
This makes hg more closely follow its own recommendation of how to deal with
versioning your builds: use hg id in your build script.
Use information provided by FindFile... Win32 calls
to generate stat information without lstat call per file.
rwx bits in st_mode are ignored as they are not stored in Win32 fs
and Mercurial does not use them
Unicode path / path names over _MAX_PATH are intentionally not supported.