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.
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.
With Python 2.5, the email package is not fully loaded by py2exe, due to
dynamic imports which are not found by modulefinder. This breaks the patchbomb
extension. This patch forces the whole email package to be included so that
the dynamic imports work as expected.
Debian Etch doesn't include a sys/inotify.h header, which makes it
impossible to compile _inotify.c, making hg uninstallable.
The cc.has_function() method is implemented by trying to compile a
simple C program. Since there's no redirection involved all error
messages are sent to the terminal. This is not particularly pretty
but at least it allows the installation to complete.
