doc: make gendoc.py module import policy aware Without this, running gendoc.py during an install without C modules available (via `make local`) will result in an import failure because the default module load policy insists on C modules. We also remove the sys.path adjustment because it is no longer needed since our magic importer handles things.

merge with stable

check-commit: add a test for the patch checking script in contrib This introduces a test for the change introduced in 8f5735b4aca5.

match: use re2 in readpatternfile if possible This has a small, but measurable, effect on performance if a pattern file is very large. In an artificial test with 200,000 lines of pattern data, using re2 reduced read time by 200 milliseconds.

test-hgignore.t: add tests for comments Although support for comments in hgignore files has existed for a while, it was previously untested.

help: fix help -c/help -e/help -k Before, hg help -c was the same as hg help, now it only shows commands. Before, hg help -e was the same as hg help, now it only shows extensions. Before, hg help -k crashed, now it shows all topics.

help: call filtercmd from topicmatch update test coverage to explicitly define when help -c should list debug/deprecated items.

help: refactor filtercmd

transplant: use Oxford comma

crecord: add dictionary to default return value of filterpatch When committing interactively without changes, the user would get a ValueError exception. This patch adds a dictionary to the return value of filterpatch when there are no files to change.

paths: include #fragment again Since 5f2a4fc3c4fa, #fragment was missing in "hg paths" output because path.loc was changed to a parsed URL. "hg paths" should use path.rawloc to show complete URLs.

discovery: properly filter changeset in 'peer.known' (issue4982) The 'peer.known' call (handled at the repository level) was applying its own manual filtering (looking at phases) instead of relying on the repoview mechanism. This led to the discovery finding more "common" node that 'getbundle' was willing to recognised. From there, bad things happen, issue4982 is a symptom of it. While situations like described in issue4982 can still happen because of race conditions, fixing 'peer.known' is important for consistency in all cases. We update the code to use 'repoview' filtering. This lead to small changes in the tests for exchanging obsolescence marker because the discovery yields different results. The test affected in 'test-obsolete-changeset-exchange.t' is a test for issue4982 getting back to its expected state.

test: add an extra base changeset in test-obsolete.t A fix to issue4982 (not fixed in this patch) will reinforce the filtering during discovery. This will makes two of our test repositories appear unrelated (because all common content is properly hidden). To avoid this, we introduce an extra base changeset that will not get obsoleted. This affects various test output so we put this addition in its own changeset.

parents: provide equivalent revsets in help

merge: refuse update/merge if there are unresolved conflicts (BC) We currently allow updating and merging (with --force) when there are unresolved merge conflicts, as long as there is only one parent of the working copy. Even worse, when updating to another revision (linearly), if one of the unresolved files (including any conflict markers in the working copy) can now be merged cleanly with the target revision, the file becomes marked as resolved. While we could potentially allow updates that affect only files that are not in the set of unresolved files, that's considerably more work, and we don't have a use case for it anyway. Instead, let's keep it simple and refuse any merge or update (without -C) when there are unresolved conflicts. Note that test-merge-local.t explicitly checks for conflict markers that get carried over on update. It's unclear if that was intentional or not, but it seems bad enough that we should forbid it. The simplest way of fixing the test case is to leave the conflict markers in place and just mark the files resolved, so let's just do that for now.

tests: drop require slow in test-contrib-perf * skip presleep * use a stub mode which does not output and generally loops only once * only use one node for perfparents

convert/svn: quiet check-config

check-config: handle multiline config

check-config: escape period in regexp for inline comments

check-config: allow numbers in configs p4...

check-config: recognize convert style documentation

tests: use a single repo for test-contrib-perf

perf: perfrevlog optimize for perf.stub

perf: add getlen getlen will return 1 if perf.stub

perf: add optional rev for perflog and perftemplating

perf: perfparents honor config perf.parentscount

perf: offer perf.stub to only run one loop

perf: improve grammar of gettimer comment

tests: use absolute_import in tinyproxy Thus begins a series of adding absolute_import to a bunch of files for Python 3 compatibility.

tests: use absolulte_import in test-wireproto.py

tests: use absolute_import in test-walkrepo

tests: use absolute_import in hgweberror.py

tests: use absolute_import in hghave.py

tests: use absolute_import for heredoctest.py

tests: use absolute_import in /get-with-headers.py While I was here, I removed condition code for failure to import json. This code was necessary to support Python < 2.6, which didn't include the json module.

tests: use absolute_import in generate-working-copy-states.py

hgweb: move entry-preparing code from webcommands to webutils.commonentry() The new function is used to fill basic information about a ctx, such as revision number and hash, author, commit message, etc. Before, every webcommand used to get this basic information on its own using some boilerplate code, and some things in some places just weren't available.

grammar: favor zero, one, two over ... or no

commands: use Oxford comma (help clone)

commit: make commit acquire store lock before processing for consistency If acquisition of wlock waits for another "hg commit" process to release it, dirstate will refer newly committed revision after acquisition of wlock. At that time, '00changelog.i' on the filesystem contains this new revision, but in-memory 'repo.changelog' doesn't, if it is cached without store lock (slock) before updating by another "hg commit". This makes validating parents at re-loading 'repo.dirstate' from '.hg/dirstate' replace such new revision with 'nullid'. Then, 'localrepository.commit()' creates "orphan" revision (see issue4368 for detail). a01d3d32b53a makes 'commands.commit()' acquire both wlock and slock before processing to avoid this issue at "hg commit". But similar issue can occur even after a01d3d32b53a, if 3rd party extension does: - refer 'repo.changelog' outside wlock scope, and - invoke 'repo.commit()' directly (instead of 'commands.commit()') This patch makes 'commit()' acquire slock before processing, to refer recent changelog at validating parents of 'repo.dirstate'.

censor: make censor acquire locks before processing Before this patch, "hg censor" executes below: - without acquisition of wlock, examine whether the working directory refers the revision of the file to be censored or not - without acquisition of store lock (slock), replace existing filelog of file to be censored with censored one, Replacement consists of steps below, and it is assumed that the destination filelog at (1) isn't changed before renaming at (3). 1. read existing filelog in 2. write filelog entries (both censored and not) into temporary file 3. rename from temporary file to existing filelog to be censored It may cause unintentional result, if another command runs parallelly (see also issue4368). This patch makes "hg censor" acquire wlock and slock before processing.

transplant: widen wlock scope of transplant for consitency while processing Before this patch, "hg transplant" executes below before acquisition of wlock. - cmdutil.checkunfinished() - repo.status() for dirty check - repo.dirstate.parents() It may cause unintentional result, if another command runs parallelly (see also issue4368). This patch makes "hg transplant" acquire wlock before processing instead of acquiring wlock in each of 'transplanter.apply()' and 'transplanter.recover()'.

shelve: remove redundant acquisition of wlock for sub commands of unshelve Previous patch ensures that wlock is acquired before processing for "hg unshelve". It makes acquisition of wlock in each functions below redundant. - unshelveabort() for "unshelve --abort" - unshelvecontinue() for "unshelve --continue"

shelve: widen wlock scope of unshelve for consistency while processing Before this patch, "hg unshelve" of shelve extension executes below before acquisition of wlock: - cmdutil.checkunfinished() - examine existence of (specified) shelve file It may cause unintentional result, if another command runs parallelly (see also issue4368). This patch widens wlock scope of "hg unshelve" of shelve extension for consistency while processing.

perf: add perflrucachedict command It measures time to construct, perform gets, sets, or mixed mode operations on a cache of configurable size with variable numbers of operations.

tests/filterpyflakes: use absolute_import

tests/fakepatchtime.py: use absolute_import

tests/fakedirstatewritetime.py: use absolute_import

tests/dumbhttp: use absolute_import

tests/autodiff.py: use absolute_import

tests/test-ancestor: use absolute_import

tests: add test for Python 3 compatibility Python 3 is inevitable. There have been incremental movements towards converting the code base to be Python 3 compatible. Unfortunately, we don't have any tests that look for Python 3 compatibility. This patch changes that. We introduce a check-py3-compat.py script whose role is to verify Python 3 compatibility of the files passed in. We add a test that calls this script with all .py files from the source checkout. The script currently only verifies that absolute_import and print_function are used. These are the low hanging fruits for Python compatbility. Over time, we can include more checks, including verifying we're able to load each Python file with Python 3. You have to start somewhere. Accepting this patch means that all new .py files must have absolute_import and print_function (if "print" is used) to avoid a new warning about Python 3 incompatibility. We've already converted several files to use absolute_import and print_function is in the same boat, so I don't think this is such a radical proposition.

merge with stable

localrepo: reinstate localrepo.parents with a deprecation warning The function was dropped in 3fe8cb40c9c5. This API drop brokes three of my extensions including some critical to my workflow like tortoisehg. Lets mark this API for death and give people time to fix their code.

bookmark: deprecate 'bmstore.write' method This function does not collaborate with the transaction and must disappear. As we have likely a lot of third party users, we make it deprecated to let them some time to upgrade their code. Thanks goes to Laurent Charignon for cleanup the last remains of the 'write' method.

ui: add a 'deprecwarn' helper to issue deprecation warnings As discussed on the list, we are adding an official way to keep old API around for a short time in order to help third party developer to catch up. The deprecated API will issue developer warning (issued by default during test runs) to warn extensions authors that they need to upgrade their code without instantaneously breaking tool chains and normal users. The version is passed as an explicit argument so that developer think about it and a potential future script can automatically check for it. This is not build as a decorator because accessing the 'ui' instance will likely be different each time. The message is also free form because deprecated API are replaced in a variety of ways. I'm not super happy about the final rendering of that message, but this is a developer oriented warning and I would like to move forward.

ui: add a 'stacklevel' argument to 'develwarn' This allows helper functions (like deprecation warning) to prepare a devel warning for higher up in the stack. The argument is named after the one in the Python's 'warning,warn' function.

import-checker: tell which symbol causes "direct symbol import" This would be sometimes useful to understand why import-checker.py complains about it.

import-checker: allow absolute imports of sub modules from local packages Before this patch, import-checker.py didn't know if a name in ImportFrom statement are module or not. Therefore, it complained the following example did "direct symbol import from mercurial". # hgext/foo.py from mercurial import hg This patch reuses the dict of local modules to filter out sub-module names.

manifest: use 't' for tree manifest flag We currently use 'd' to indicate that a manifest entry is a directory. Let's switch to 't', since that's not a valid hex digit and therefore easier to spot in the raw manifest data. This will break any existing repos with tree manifests, but it's still an experimental feature and there are probably only a few test repos in existence with 'd' flags.

test: update the docstring of 'test-devel-warnings.t' extension We are testing more than just locks now.

setup.py: don't rewrite @LIBDIR@ when creating wheels This is necessary to produce wheels that install properly. More details are captured in an in-line comment. After this patch, produced wheels can be installed via `pip install` and appear to "just work," including on Windows.

setup.py: attempt to build and install hg.exe on Windows Currently, packaging Mercurial on Windows will produce a Scripts\hg Python script and a Scripts\hg.bat batch script. The py2exe distribution contains a hg.exe which loads a Python interpretter and invokes the "hg" Python script. Running a exe directly has benefits over batch scripts because batch scripts do things like muck around with command arguments. This patch implements a custom "build_scripts" command which attempts to build hg.exe on Windows. If hg.exe is built, it is marked as a "script" file and installed into the Scripts\ directory on Windows. Since hg.exe is redundant and better than hg.bat, if hg.exe is built, hg.bat is not installed. Since some environments don't support compiling C programs, we treat hg.exe as optional and catch failures building it. This is not ideal. However, I reckon most Windows users will not be installing Mercurial from source: they will get it from the MSI installer or via `pip install Mercurial`, which will download a wheel that has hg.exe in it. So, I don't think this is a big deal.

merge.graft: add option to keep second parent Currently merge.graft re-writes the dirstate so only a single parent is kept. For some cases, like evolving a merge commit, this behaviour is not desired. More specifically, this is needed to fix issue4389.

ui: support declaring path push urls as sub-options Power users often want to apply per-path configuration options. For example, they may want to declare an alternate URL for push operations or declare a revset of revisions to push when `hg push` is used (as opposed to attempting to push all revisions by default). This patch establishes the use of sub-options (config options with ":" in the name) to declare additional behavior for paths. New sub-options are declared by using the new ``@ui.pathsuboption`` decorator. This decorator serves multiple purposes: * Declaring which sub-options are registered * Declaring how a sub-option maps to an attribute on ``path`` instances (this is needed to `hg paths` can render sub-options and values properly) * Validation and normalization of config options to attribute values * Allows extensions to declare new sub-options without monkeypatching * Allows extensions to overwrite built-in behavior for sub-option handling As convenient as the new option registration decorator is, extensions (and even core functionality) may still need an additional hook point to perform finalization of path instances. For example, they may wish to validate that multiple options/attributes aren't conflicting with each other. This hook point could be added later, if needed. To prove this new functionality works, we implement the "pushurl" path sub-option. This option declares the URL that `hg push` should use by default. We require that "pushurl" is an actual URL. This requirement might be controversial and could be dropped if there is opposition. However, objectors should read the complicated code in ui.path.__init__ and commands.push for resolving non-URL values before making a judgement. We also don't allow #fragment in the URLs. I intend to introduce a ":pushrev" (or similar) option to define a revset to control which revisions are pushed when "-r <rev>" isn't passed into `hg push`. This is much more powerful than #fragment and I don't think #fragment is useful enough to continue supporting. The [paths] section of the "config" help page has been updated significantly. `hg paths` has been taught to display path sub-options. The docs mention that "default-push" is now deprecated. However, there are several references to it that need to be cleaned up. A large part of this is converting more consumers to the new paths API. This will happen naturally as more path sub-options are added and more and more components need to access them.

ui: pass ui instance to path.__init__ It will be used in a subsequent patch.

ui: store pushloc as separate attribute The magic @property is going to interfere with the ability to print path sub-options. We only access it in one location and it is trivial to in-line, so do that.

commands: add debugdeltachain command We have debug commands for displaying overall revlog statistics (debugrevlog) and for dumping a revlog index (debugindex). As part of investigating various aspects of revlog behavior and performance, I found it important to have an understanding of how revlog delta chains behave in practice. This patch implements a "debugdeltachain" command. For each revision in a revlog, it dumps information about the delta chain. Which delta chain it is part of, length of the delta chain, distance since base revision, info about base revision, size of the delta chain, etc. The generic formatting facility is used, which means we can templatize output and get machine readable output like JSON. This command has already uncovered some weird history in mozilla-central I didn't know about. So I think it's valuable.

histedit: pick an appropriate base changeset by default (BC) Previously, `hg histedit` required a revision argument specifying which revision to use as the base for the current histedit operation. There was an undocumented and experimental "histedit.defaultrev" option that supported defining a single revision to be used if no argument is passed. Mercurial knows what changesets can be edited. And in most scenarios, people want to edit this history of everything on the current head that is rewritable. Making histedit do this by default and not require an explicit argument or additional configuration is a major usability win and will enable more people to use histedit. This patch changes the behavior of the experimental and undocumented "histedit.defaultrev" config option to select an appropriate base revision by default. Comprehensive tests exercising the edge cases in the new, somewhat complicated default revset have been added. Surprisingly, no tests broke. I guess we were never testing the behavior with no ANCESTOR argument (it used to fail with "abort: histedit requires exactly one ancestor revision"). The new behavior is much more user friendly. The functionality for choosing the default base revision has been moved to destutil.py, where it can easily be modified by extensions.

rebase: remove extra "if" from check of collapsing named branches

rebase: drop redundant functions to keep branch and graft source explicitly All entries in extra dict are propagated by default since 88fde8db5307.

color: drop useless override of ui.popbuffer() Because labels are applied at write() time since 717b75ae5bb0, colorui.popbuffer() is useless and it doesn't update _bufferapplylabels correctly. Removing it should fix the problem.

repoview: bypass changelog method to computed cache key Getting the data necessary for the cache key using the changelog/revlog method adds a significant overhead. Given how simple the underlying implementation is and often this code is ran, it makes sense to violate layering and directly compute the data. Testing `hg log` on Mozilla-central, this reduce the time spent on changelog cache validation by an extra half: before: 12.2s of 69s after: 6.1s of 62s Total speed up from this patch and it's parent is 3x (With stupid python profiler overhead) The global speedup without profiler overhead is still there, Before: 51s After: 39s (-23%)

repoview: stop recomputing cached key in all case As explained in the comment, we were computing the key of the cache value every time because of some obscure MQ test failure. I've dropped that code and ran the test again that failure is gone. I assume some transaction cleanup got rid of it. So we are dropping that code. This provide a significant speedup. Testing `hg log` on Mozilla-central this reduce the time spent on changelog cache validation by a third: before: 19.5s of 80s after: 12.2s of 69s (With stupid python profiler overhead)

commands.debugindexdot: use cmdutil.openrevlog() This pattern is used for all the other debug* commands that operate on revlogs. debugindexdot is an outlier. Make it conform.

commands: unify argument handling for revlog debug commands The same 3 options are used in a few locations and I'm about to add another. Might as well consolidate the pattern.

commit: fix rest syntax of examples This fixes the formatting of help/commit page and silence test-gendoc.t.

ui: optionally ignore sub-options from configitems() For convenience.

ui: add method to return option and all sub-options Apparently ":" has been blessed as a generic separator for options and sub-options. We formalize this by introducing an API for obtaining an option and all its sub-options. This will be used in a subsequent patch for declaring sub-options for [paths].

revlog: don't consider nullrev when choosing delta base In the most complex case, we try using the incoming delta base, then we try both parents, and then we try the previous revlog entry. If none of these result in a good delta, we natually use the null revision as base. However, we sometimes consider the nullrev before we have exhausted our other options. Specifically, when both parents are null, we use the nullrev as delta base if it produces a good delta (according to _isgooddelta()), and we fail to try the previous revlog entry as delta base. After 20a9226bdc8a (addrevision: use general delta when the incoming base delta is bad, 2015-12-01), it can also happen for non-merge commits when the incoming delta is not good. The Firefox repo (from many months back) shrinks a tiny bit with this patch: from 1.855GB to 1.830GB (1.4%). The hg repo itself shrinks even less: by less than 0.1%. There may be repos that get larger instead. This undoes the unexplained test change in 20a9226bdc8a.

revlog: make calls to _isgooddelta() consistent We always want to call _isgooddelta() before accepting a delta. We mostly call the function right after building the delta, but not always. Instead, we have an extra call at the end of the big code block. Let's make it consistent, so we call _isgooddelta() right after builddelta() and exactly once per delta. That also lets us rely on "delta is None" to mean we didn't find a good delta.

revlog: clarify which revision is added to 'tested' when using cached delta The tested delta revisions are added to the 'tested' set. These are the same revisions we pass to builddelta(). However, in one case, we add builddelta(rev)[3] to the set intead of adding 'rev' itself. In that particular case, that element is the same as the function's input revision (because self._generaldelta is true), so the effect is the same. Still, let's just add the function's input revision to avoid confusing future readers.

revlog: remove unused variable 'chainlen'

commit: adjust the quoting in the examples to be Windows friendly We should probably avoid strong quotes around command line args in the examples, since cmd.exe doesn't recognize them, and it will surprise a user who cargo cults them. I don't see a way to make a rule for this, since strong quoting is OK inside command line args, like within revsets.

wireproto: config options to disable bundle1 bundle2 is the new and preferred wire protocol format. For various reasons, server operators may wish to force clients to use it. One reason is performance. If a repository is stored in generaldelta, the server must recompute deltas in order to produce the bundle1 changegroup. This can be extremely expensive. For mozilla-central, bundle generation typically takes a few minutes. However, generating a non-gd bundle from a generaldelta encoded mozilla-central requires over 30 minutes of CPU! If a large repository like mozilla-central were encoded in generaldelta and non-gd clients connected, they could easily flood a server by cloning. This patch gives server operators config knobs to control whether bundle1 is allowed for push and pull operations. The default is to support legacy bundle1 clients, making this patch backwards compatible.

dockerlib: short form for non-unique uid/gid for CentOS 5 compat (issue4977) CentOS 5 does not support '--non-unique', but does support the short '-o'.

exchange: standalone function to determine if bundle2 is requested This will be used in a subsequent patch.

wireproto: add docstring for wirepeer

commit: add some help examples (issue4963) Includes documenting --date now, which resolves the above issue.

changegroup: restate file linknode callback using generator expressions I think this is slightly clearer, and it nicely avoids an extra nested function.

changegroup: clean up file lookup function One case is basically degenerate, so just extract it and make the function clearer.

changegroup: remove one special case from lookupmflinknode In the fastpathlinkrev case, lookupmflinknode was a very complicated way of saying mfs.__getitem__, so let's just get that case out of our way so it's easier to understand what's going on.

changegroup: drop 'if True' that made the previous change clearer

changegroup: avoid iterating the whole manifest The old code gathered the list of all files that changed anywhere in history and then gathered changed file nodes by walking the entirety of each manifest to be sent in order to gather changed file nodes. That's going to be unfortunate for narrowhg, and it's already inefficient for medium-to-large repositories. Timings for bundle --all on my hg repo, tested with hgperf: Before: ! wall 23.442445 comb 23.440000 user 23.250000 sys 0.190000 (best of 3) After: ! wall 20.272187 comb 20.270000 user 20.190000 sys 0.080000 (best of 3)

posix: work around "posix" systems without os.link available (issue4974) Some platforms (see bug, notably a terminal emulator on Android) ship with os.link removed from Python to try and cater to other tools that expect os.link to exist iff hardlinks are supported on that platform. As a workaround for this madness, include a fallback path for when we're on a "posix" platform but lack os.link.

pathutil: use temporary variables instead of complicated wrapping The one-lining did not help readability, we get rid of it.

context: use a the nofsauditor when matching file in history (issue4749) Before this change, asking for file from history (eg: 'hg cat -r 42 foo/bar') could fail because of the current content of the working copy (eg: current "foo" being a symlink). As the working copy state have no influence on the content of the history, we can safely skip these checks. The working copy context class have a different 'match' implementation. That implementation still use the repo.auditor will still catch symlink traversal. I've audited all stuff calling "match" and they all go through a ctx in a sensible way. The most unclear case was diff which still seemed okay. You raised my paranoid level today and I double checked through tests. They behave properly. The odds of someone using the wrong (matching with a changectx for operation that will eventually touch the file system) is non-zero because you are never sure of what people will do. But I dunno if we can fight against that. So I would not commit to "never" for "at this level" and "in the future" if someone write especially bad code. However, as a last defense, the vfs itself is running path auditor in all cases outside of .hg/. So I think anything passing the 'matcher' for buggy reason would growl at the vfs layer.

localrepo: add a second auditor without file system check Auditors keeps a cache of audited paths. Therefore we cannot use the same auditor for working copy and history operation. We create a new one without file system check for this purposes.

pathauditor: add a way to skip file system check We need to be able to skip it when looking at data within the history. Doing them in all cases leads to buggy behavior like issue4749.

pathauditor: move file system specific check in their own function This will make it easy to disable that part when not relevant (eg: auditing filename for operation in history)

contrib: disable SSLv3_method() to build old Python with recent libssl Because OpenSSL is compiled without SSLv3 support on Debian sid, Python 2.6.9 can't be built without this hack. Python 2.7 is patched appropriately, but 2.6 isn't. http://bugs.python.org/issue22935

rebase: only clear rebase status after the rebase transaction has completed In 405320cd6198, I made the mistake of moving the step "clearing the status after a rebase" to inside the rebase transaction. This was wrong, since we don't want to clear the status (and the rebase state) if something went wrong during the transaction: if something goes wrong we want to keep the rebase state to be able to abort. It broke rebase with evolve + inhibit.

dirstate: don't write repo.currenttransaction to repo.dirstate if repo is None (issue4983) Some hooks, such as post-init and post-clone, do not get a repo parameter in their environment. If there is no repo, there is no repo.currenttransaction(); attempting to retrieve it anyway was causing crashes. Now currenttransaction is only retrieved and written if the repo is not None.

tests: test changegroup generation for filtered changesets (issue4982) The test demonstrates the buggy behavior from issue4982 where the changegroup contains changesets it shouldn't.

parsers: fix parse_dirstate to check len before unpacking header (issue4979)

mercurial: support loading modules from zipimporter The previous refactor to module importing broke module loading when mercurial.* modules were loaded from a zipfile (using a zipimporter). This scenario is likely encountered when using py2exe. Supporting zipimporter and the traditional importer side-by-side turns out to be quite a pain. In Python 2.x, the standard, file-based import mechanism is partially implemented in C. The sys.meta_path and sys.path_hooks hook points exist to allow custom importers in Python/userland. zipimport.zipimporter and our "hgimporter" class from earlier in this patch series are 2 of these. In a standard Python installation (no matter if running in py2exe or similar or not), zipimport.zipimporter appears to be registered in sys.path_hooks. This means that as each sys.path entry is consulted, it will ask zipimporter if it supports that path and zipimporter will be used if that entry is a zip file. In a py2exe environment, sys.path contains an entry with the path to the zip file containing the Python standard library along with Mercurial's Python files. The way the importer mechanism works is the first importer that declares knowledge of a module (via find_module() returning an object) gets to load it. Since our "hgimporter" is registered in sys.meta_path and returns an interest in specific mercurial.* modules, the zipimporter registered on sys.path_hooks never comes into play for these modules. So, we need to be zipimporter aware and call into zipimporter to load modules. This patch teaches "hgimporter" how to call out into zipimporter when necessary. We detect the necessity of zipimporter by looking at the loader for the "mercurial" module. If it is a zipimporter instance, we load via zipimporter. The behavior of zipimporter is a bit wonky. You appear to need separate zipimporter instances for each directory in the zip file. I'm not sure why this is. I suspect it has something to do with the low-level importing mechanism (implemented in C) operating on a per-directory basis. PEP-302 makes some references to this. I was not able to get a zipimporter to import modules outside of its immediate directory no matter how I specified the module name. This is why we use separate zipimporter instances for the ".zip/mercurial" and ".zip/mercurial/pure" locations. The zipimporter documentation for Python 2.7 explicitly states that zipimporter does not import dynamic modules (C extensions). Yet from a py2exe distribution on Windows - where the .pyd files are *not* in the zip archive - zipimporter imported these dynamic modules just fine! I'm not sure if dynamic modules can't be imported from *inside* the zip archive or whether zipimporter looks for dynamic modules outside the zip archive. All I know is zipimporter does manage to import the .pyd files on Windows and this patch makes our new importer compatible with py2exe. In the ideal world, We'd probably reimplement or fall back to parts of the built-in import mechanism instead of handling zipimporter specially. After all, if we're loading Mercurial modules via something that isn't the built-in file-based importer or zipimporter, our custom importer will likely fail because it doesn't know how to call into it. I'd like to think that we'll never encounter this in the wild, but you never know. If we do encounter it, we can come up with another solution. It's worth nothing that Python 3 has moved a lot of the importing code from C to Python. Python 3 gives you near total control over the import mechanism. So in the very distant future when Mercurial drops Python 2 support, it's likely that our custom importer code can be refactored to something a bit saner.

mercurial: don't load C extensions from PyPy PyPy isn't compatible with Python C extensions. With this patch, the module load policy is automatically to "Python only" when run under PyPy. `hg` and other Python scripts importing mercurial.* modules will run from the source checkout or any installation when executed with PyPy. This should enable people to more easily experiment with PyPy and its potentially significant performance benefits over CPython!

mercurial: be more strict about loading dual implemented modules With this change in place, we should have slightly stronger guarantees about how modules with both Python and C implementations are loaded. Before, our module loader's default policy looked under both mercurial/* and mercurial/pure/* and imported whatever it found, C or pure. The fact it looked in both locations by default was a temporary regression from the beginning of this series. This patch does 2 things: 1) Changes the default module load policy to only load C modules 2) Verifies that files loaded from mercurial/* are actually C modules This 2nd behavior change makes our new module loading mechanism stricter than from before this series. Before, it was possible to load a .py-based module from mercurial/*. This could happen if an old installation orphaned a file and then somehow didn't install the C version for the new install. We now detect this odd configuration and fall back to loading the pure Python module, assuming it is allowed. In the case of a busted installation, we fail fast. While we could fall back, we explicitly decide not to do this because we don't want people accidentally not running the C modules and having slow performance as a result.

setup: refactor handling of modules with C/Python implementations Previously, .py files under mercurial/pure/ were copied to mercurial/* during installation if we were performing a pure Python installation. Now that the new import hooks and module load policy are in place, this hackery from the past is no longer necessary. With this patch, we stop copying modules from mercurial/pure/* to mercurial/*. Instead, we preserve the files at their original hierarchy, mirroring the source repository structure. In addition, we always install the pure modules. Before, we would only include the pure modules in the distribution/installation if the install-time settings requested a pure Python installation. The upside of this change is that CPython and PyPy can run from the same Mercurial installation, making packaging and distribution of Mercurial simpler. The inclusion of pure Python modules in the installation sounds risky, as it could lead to inadvertent loading of non-C modules. This shouldn't be a problem. The default module load policy is "C only" (or at least will be shortly) and the only way to load pure modules from an installation is if a) pure installation was requested b) the HGMODULELOADPOLICY overrides the requirement for C modules. The default module load policy as defined in source is a special string whose default value from the checkout is equivalent to the "C only" policy (again, not exactly the state right now). For pure installations, this default policy is not appropriate and will not work. This patch adds support for rewriting __init__.py during installation to reflect the module load policy that should be in place accoding to the installation settings. For default CPython installs, the value in the source file will change but there will be no functional change. For pure installations, the default policy will be set to "py," allowing them to work without having to set environment variables.

check-seclevel: set module load policy to Python only If we don't change this, the upcoming change to make the module loading policy only load C modules will cause this script to fail if run with CPython against an unbuilt source checkout.

mercurial: implement import hook for handling C/Python modules There are a handful of modules that have both pure Python and C extension implementations. Currently, setup.py copies files from mercurial/pure/*.py to mercurial/ during the install process if C extensions are not available. This way, "import mercurial.X" will work whether C extensions are available or not. This approach has a few drawbacks. First, there aren't run-time checks verifying the C extensions are loaded when they should be. This could lead to accidental use of the slower pure Python modules. Second, the C extensions aren't compatible with PyPy and running Mercurial with PyPy requires installing Mercurial - you can't run ./hg from a source checkout. This makes developing while running PyPy somewhat difficult. This patch implements a PEP-302 import hook for finding and loading the modules with both C and Python implementations. When a module with dual implementations is requested for import, its import is handled by our import hook. The importer has a mechanism that controls what types of modules we allow to load. We call this loading behavior the "module load policy." There are 3 settings: * Only load C extensions * Only load pure Python * Try to load C and fall back to Python An environment variable allows overriding this policy at run time. This is mainly useful for developers and for performing actions against the source checkout (such as installing), which require overriding the default (strict) policy about requiring C extensions. The default mode for now is to allow both. This isn't proper and is technically backwards incompatible. However, it is necessary to implement a sane patch series that doesn't break the world during future bisections. The behavior will be corrected in future patch. We choose the main mercurial/__init__.py module for this code out of necessity: in a future world, if the custom module importer isn't registered, we'll fail to find/import certain modules when running from a pure installation. Without the magical import-time side-effects, *any* importer of mercurial.* modules would be required to call a function to register our importer. I'm not a fan of import time side effects and I initially attempted to do this. However, I was foiled by our own test harness, which has numerous `python` invoked scripts that "import mercurial" and fail because the importer isn't registered. Realizing this problem is probably present in random Python scripts that have been written over the years, I decided that sacrificing purity for backwards compatibility is necessary. Plus, if you are programming Python, "import" should probably "just work." It's worth noting that now that we have a custom module loader, it would be possible to hook up demand module proxies at this level instead of replacing __import__. We leave this work for another time, if it's even desired. This patch breaks importing in environments where Mercurial modules are loaded from a zip file (such as py2exe distributions). This will be addressed in a subsequent patch.

changegroup: document manifest linkrev callback some more Martin and I just got super-confused reading some code here, so I think it's time for some more documentation.

changegroup: note during bundle apply if the repo was empty An upcoming change for exchanging treemanifest data will need to update the repository capabilities, which we should only do if the repository was empty before we started applying this changegroup. In the future we will probably need a strategy for upgrading to treemanifest in requires during a pull (I'm assuming at some point we'll make it possible to have a flag day to enable treemanifests on an existing history.)

histedit: improve missing rule suggestion include actual suggested text

graphlog: make node symbol templatable by ui.graphnodetemplate option New ui.graphnodetemplate option allows us to colorize a node symbol by phase or branch, [ui] graphnodetemplate = {label('graphnode.{phase}', graphnode)} [color] graphnode.draft = yellow bold or use a variety of unicode emoji characters, and so on. (You'll need less-481 to display non-BMP unicode character.) [ui] graphnodetemplate = {ifeq(obsolete, 'stable', graphnode, '\xf0\x9f\x92\xa9')}

templatekw: avoid slow creation of changectx objects in showgraphnode() This mitigates the minor perf regression introduced by the previous patch. % hg log -G -R mozilla-central -l10000 --time > /dev/null (original) real 2.200 secs (previous) real 2.590 secs (this) real 2.280 secs

graphlog: extract "graphnode" template keyword that represents node symbol This provides a default node symbol. Tests will be added later. "showparents" variable is renamed to "wpnodes" to avoid confusion with the existing showparents() function.

graphlog: move creation of workingdir-parent nodes to displaygraph() Future patches will make a node symbol templatable. Because arguments of a templatekw function are repo and ctx, "showparents" list will have to be built from a repo object by that function.

builddeb: read default distribution and codename from lsb_release This makes `make deb` place packages into a more appropriately named directory instead of just "debian-unknown".

builddeb: remove unused --debbuilddir option Looks like it was never used and after 7f49efcaa9b4 it can be removed.