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.

builddeb: add --distid option to specify Distributor ID This allows builddeb to handle distributions that are not Debian. Distributor ID is reported by lsb_release --id, and in case of builddeb it's usually Debian or Ubuntu.

builddeb: rename --release option to --codename Debian and Ubuntu releases have both codenames and traditional version numbers. An entire "branch" of releases is referred to by its codename, and version numbers (e.g. 8.2, 14.04.3) are used to address individual releases. Since we use codenames for building .deb packages, let's call the option and the variable appropriately.

histedit: get rid of state.rules Now we are using state.actions instead of state.rules everywhere.

histedit: change state.rules uses to state.actions This change is replacing most of state.rules uses with state.actions uses. The next change will change histeditstate class to actually uses state actions.

histedit: add tostate method to histedit action the format of rules that we store in state file format is different from the rule format that we present to users. We need a way of dumping action to state file.

histedit: remove makedesc It's a dead code now.

histedit: use torule instead of makedesc in ruleeditor

histedit: add torule method to histedit action objects To make histedit action objects responsible for understanding the format of their action lines we are adding a torule method which for a histedit action will return a string which can be saved in histedit state or shown in text editor when editing the plan.

histedit: add verify() to histeditaction This commits splits the parsing of the histedit rule from its semantic analysis. It's necessary because sometimes we want to do first without doing the former (reading the histedit state).

histedit: add addhisteditaction decorator This decorator will is allowing us to move the registering the action in actiontable closer to the action code. Also it is storing the verb inside histedit action so the action is aware of the verb needed to trigger it.

histedit: add actions property to histedit state I want to refactor histedit to use action objects instead of (verb, rest) pairs whenever possible. At the end of this series I want the rules to be translated into action objects when reading state and translated back when writing state. All histedit internals should use action objects instead of state rules. To migrate histedti internals sequentially I'm introducing the state.actions property to translate rules on the fly so we can use both state.actions and state.rules until refactoring is done.

check-commit: remove confusion between summary line and other headers The pull url header can easily grow over 80 chars. The check-commit script was confusing this with a too long summary line. We update the regular expression to not match other header.

shelve: execute checkunfinished inside wlock scope Before this patch, "hg shelve" of shelve extension executes 'cmdutil.checkunfinished()' before acquisition of wlock. It may cause unintentional result, if another command runs parallelly (see also issue4368). To avoid this issue, this patch executes 'cmdutil.checkunfinished()' inside wlock scope of "hg shelve". This also fixes issue4957, because now 'cmdutil.checkunfinished()' isn't invoked at "hg shelve" with options below: --cleanup --delete --list --patch --stat

shelve: widen wlock scope of shelve for consistency while processing Before this patch, "hg shelve" of shelve extension executes/refers below before acquisition of wlock: - 'repo.dirstate.parents()' via 'repo[None].parents()' - 'repo._activebookmark' It may cause unintentional result, if another command runs parallelly (see also issue4368). This patch widens wlock scope of "hg shelve" of shelve extension for consistency while processing.

gpg: make sign acquire wlock before processing Before this patch, "hg sign" of gpg extension executes/evaluates below without acquisition of wlock. - repo.dirstate.parents() - '.hgsigs' not in repo.dirstate It may cause unintentional result, if another command runs parallelly (see also issue4368). To avoid this issue, this patch makes "hg sign" of gpg extension acquire wlock before processing.

commands: execute checkunfinished and bailifchanged inside wlock scope Before this patch, "hg import" executes below before acquisition of wlock: - cmdutil.checkunfinished() - cmdutil.bailifchanged() It may cause unintentional result, if another command runs parallelly (see also issue4368). To avoid this issue, this patch executes 'cmdutil.checkunfinished()' and 'cmdutil.bailifchanged()' inside wlock scope of "hg import".

commands: widen wlock scope of graft for consitency while processing Before this patch, "hg graft" executes below before acquisition of wlock. - cmdutil.checkunfinished() - cmdutil.bailifchanged() - repo.dirstate.parents() via 'repo["."]' - unlinking '.hg/graftstate' It may cause unintentional result, if another command runs parallelly (see also issue4368). This patch widens wlock scope of "hg graft" for consitency while processing.