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.

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.

commands: make backout acquire locks before processing Before this patch, "hg backout" executes below before acquisition of wlock. - cmdutil.checkunfinished() - cmdutil.bailifchanged() - repo.dirstate.parents() It may cause unintentional result, if another command runs parallelly (see also issue4368). In addition to it, "hg backout" refers changelog for purposes below without acquisition of store lock (slock), and it may cause unintentional result, if store is updated parallelly. - show and update to the revision by 'repo.changelog.tip()' - examine for "created new head" by 'repo.branchheads()' and 'cmdutil.commitstatus()' To avoid this issue, this patch makes "hg backout" acquire wlock and slock before processing.

commands: make commit acquire locks before processing (issue4368) Before this patch, "hg commit" (process A) executes steps below: 1. get current branch heads via 'repo.branchheads()' - cache 'repo.changelog' 2. invoke 'repo.commit()' 3. acquire wlock - invalidate 'repo.dirstate' 4. access 'repo.dirstate' - re-read '.hg/dirstate' - check validity of parent revisions with 'repo.changelog' 5. invoke 'repo.commitctx()' 6. acquire store lock (slock) - invalidate 'repo.changelog' 7. do committing 8. release slock 9. release wlock 10. check new branch head (via 'cmdutil.commitstatus()') If acquisition of wlock at (3) above waits for another "hg commit" (process B) or so running parallelly to release wlock, process A causes creating orphan revision, because: - '.hg/dirstate' refers the revision, which is newly added by process B, as its parent - but already cached 'repo.changelog' doesn't contain such revision - therefore, validating parents of '.hg/dirstate' at (4) above replaces such revision with 'nullid' Then, process A creates "orphan" revision, of which parent is "null" revision. In addition to it, "created new head" may be shown at the end of process A unintentionally, if store is updated parallelly, because both getting branch heads (1) and checking new branch head (10) are executed outside slock scope. To avoid this issue, this patch makes "hg commit" acquire wlock and slock before processing. This patch resolves the issue between "hg commit" processes, but not one between "hg commit" and other commands. Subsequent patches resolve the latter. Even after this patch, there are still corner case problems below: - filecache may overlook changes of '.hg/dirstate', and it causes similar issue (see below for detail) https://bz.mercurial-scm.org/show_bug.cgi?id=4368#c10 - 3rd party extension may cause similar issue, if it directly uses 'repo.commit()' without acquisition of wlock and slock This can be fixed by acquisition of slock at the beginning of 'repo.commit()', but it seems suitable for "default" branch In fact, acquisition of slock itself is already introduced at "default" branch by 4414d500604f, but acquisition is not at the beginning of 'repo.commit()'. This patch also changes some tests: - test-fncache.t needs this tricky wrapping, to release (= forced failure of) wlock certainly - order of "hg commit" output is changed by widening scope of locks, because some hooks are fired after releasing wlock

addrevision: use general delta when the incoming base delta is bad We unify the delta selection process to be a simple three options process: - try to use the incoming delta (if lazydeltabase is on) - try to find a suitable parents to delta against (if gd is on) - try to delta against the tipmost revision The first of this option that yield a valid delta will be used. The test change in 'test-generaldelta.t' show this behavior as we use a delta against the parent instead of a full delta when the incoming delta is not suitable. This as some impact on 'test-bundle.t' because a delta somewhere changes. It does not seems to change the test semantic and have been ignored.

test: use a bigger manifest in general delta test The currently used manifest is too small and cannot sustain a chain length above "1". This make testing the 'lazybasedelta' behavior hard. So we add an extra file in the manifest to help testing in the next changeset. The semantic of existing tests have been checked and is not changed.

addrevision: rework generaldelta computation The old code have multiple explicit tests and code duplications. This makes it hard to improve the code. We rewrite the logic in a more generic way, not changing anything of the computed result. The final goal here is to eventually be able to: - factor out the default fallback case "try against 'prev'" in a single place - allow 'lazydeltabase' case to use the smarter general delta code path when the incoming base does not provide us with a good delta.

bmstore: close file in a finally block in _writerepo Also rename the variable to file_ to avoid shadowing a builtin.

bmstore: add basic clean-state tracking I'm about to move active-bookmark management into the bmstore. I'd like to avoid re-writing the bookmarks data (as distinct from the active bookmark file) if possible, so let's introduce some dirty-tracking early.

bookmarks: hoist getbkfile out of bmstore class It's totally fine that this hook exists, but I don't see a need for it to live inside the bmstore class.

bookmarks: document getbkfile method I'm working on bmstore again, and this function gave me a moment's pause. Document it to save future readers from any undue confusion.

hgweb: load server settings from --web-conf (issue4699) It copies the ui before loading the webconf and passes the copied ui only to the service. This way, the hgwebdir app can reload configs cleanly.

extdiff: correctly handle deleted subrepositories (issue3153) Previously, when extdiff was called on two changesets where a subrepository had been removed, an unexpected KeyError would be raised. Now, the missing subrepository will be ignored. This behavior mirrors the behavior in diffordiffstat from cmdutil.py line ~1138-1153. The KeyError is caught and the revision is set to None. try/catch of LookupError around matchmod.narrowmatcher and sub.status is removed, as LookupError is not raised anywhere within those methods or deeper calls.

hgweb: make sure command options are set to all ui objects Before this patch, it was unclear why the httpservice object could read the server options (e.g. --port) from 'ui'. It just worked because repo.ui is ui.

hgweb: eliminate duck-typing to select hgweb or hgwebdir by command option Since createservice() was moved to hgweb and hgweb imports both hgweb_mod and hgwebdir_mod, we no longer have to force hgweb() function to select one of them by the type of 'o' variable. Let's be explicit! This patch does not change hgweb() function because it is the interface of existing WSGI and CGI scripts.

addrevision: only use the incoming base if it is a good delta (issue4975) Before this change, the 'lazydeltabase' would blindly build a delta using the base provided by the incoming bundle and try to use it. If that base was far down the revlog, the delta would be seen as "no good" and we would fall back to a full text revision. We now check if the delta is good and fallback to a computing a delta again the tipmost revision otherwise (as we would do without general delta). Later changesets will improve the logic to compute the fallback delta using the general delta logic.

addrevision: handle code path not producing delta We would like to be able to exit the delta generation block without a valid delta (for a more flexible control flow). So we make sure we do not expand the "delta" content unless we actually have a delta. We can do it one level lower because 'delta' is initialised at None anyway. Not adding a level to the assignment prevent a line length issue.

addrevision: rename 'd' to 'delta' That variable is quite central to the whole function. Giving it a more explicit name help with code readability.

strip: add a --keep test related to removing files from dirstate When strip builds the list of changedfiles to pass into dirstate.rebuild, it adds files blindly, including those that have been removed. This tests ensures that rebuild can handle this case.

dirstate: change debugrebuilddirstate --minimal to use dirstate.rebuild When debugrebuilddirstate --minimal is called, rebuilding the dirstate was done outside of the appropriate rebuild function. This patch makes debugrebuilddirstate use dirstate.rebuild. This was done to allow our extension to become aware debugrebuilddirstate --minimal

debugrebuilddirstate: added tests for --minimal flag Added tests for debugrebuilddirstate --minimal.

debugdirstate: add command to rebuildstate test to modify dirstate Debugging the dirstate helps if you have options to add files for normal lookup or drop them from the dirstate. This patch adds a convenience command to test-rebuilddirstate.t to modify the dirstate. It will be used in the next patch to write proper tests for debugrebuilddirstate --minimal

graft: improve --continue abort message before, if you ran hg graft --user ... --date ... --log ... revs, and if it failed, it would suggest "hg graft --continue", but if you did that, your --user / --date / --log options were lost, because they were not persisted anywhere...

summary: mention graft

histedit: mention histedit-last-edit.txt on abort Users may spend a lot of effort writing histedit rules, getting an abort without being told they can recover their work is very frustrating. Avoid that by telling them where to find their work.

histedit: add missing raise keyword to statement

histedit: improve grammar for _histedit comment

test-fncache: ensure lock doesn't look held to __del__ This was showing a DeprecationWarning on Python 2.6.

commands: inline definition of localrepo.parents() and drop the method (API) localrepo.parents() has relatively few users, and most of those were actually implicitly looking at the wctx, which is now made explicit via repo[None].

localrepo: document nodebookmarks

localrepo: remove clone method by hoisting into hg.py hg.py was the only remaining caller of localrepo.clone(), so it's time to move some more behavior out of localrepo.

filemerge: default regular prompts to 'leave unresolved' (BC) It makes far more sense to leave these conflicts unresolved and kick back to the user than to just assume that the local version be chosen. There are almost certainly buggy scripts and applications using Mercurial in the wild that do merges or rebases non-interactively, and then assume that if the operation succeeded there's nothing the user needs to pay attention to.

filemerge: add a 'leave unresolved' option to change/delete prompts We're going to make this option the default in an upcoming patch.

filemerge: add a 'leave unresolved' option to regular prompts 'Regular' here means anything that isn't a change/delete prompt. We'll add this option to change/delete prompts in a subsequent patch.

filemerge: add debug output for whether this is a change/delete conflict Just like binary and symlink conflicts, change/delete conflicts influence the tool picked.

webcommands: test that fctx is not None in filediff() A block of code above this one already says "if fctx is not None", and it's also what this code actually intends to check, so let's be specific as PEP-8 recommends.

webcommands: stop using ersatz if-else ternary operator for rename variable 6ddc86eedc3b didn't remove it, let's do it now. Placing the added lines into the already existing "if fctx is not None" block also makes webcommands.comparison() look a bit more like webcommands.filediff(), which eases possible future refactoring. And fctx is not None only when path in ctx, so logically it's equivalent.

webcommands: get correct parents when comparing a removed file (issue4962) When comparing a file that was removed at the current revision, parents used to show grandparents instead, due to how fctx was "shifted" from the current revision to its p1. Let's not do that. The fix is pretty much copied from webcommands.filediff().

repair: use bookmarks.recordchange instead of bookmarks.write Before this patch we were using the deprecated bookmarks.write api. This patch replaces the call to bookmarks.write by a call to bookmarks.recordchange. We move the bookmark code above the code removing the undo file because with bookmarks.recordchange we have to create a transaction that would create an undo file.

commit: add amend mode for commit -i When I moved crecord into core, I didn't include the toggleAmend function (to switch from commit to amend mode). I did it because it would have made it more difficult to use record and crecord interchangably. This patch reintroduces the amend mode for commit -i as well as two tests to verify the behavior of the function.

commit: add a way to return more information from the chunkselector Before this patch, the chunkselector for record or crecord was used to return the list of hunks that were selected by the user. The goal of this series is to reintroduce the toggle amend feature for crecord. To do so, we need to be able to return more than just the selected hunks from the chunkselector but also the information: is amend mode toggled. This patch adds a new return value for chunkselectors that will be used to implement the toggle amend feature in crecord.

histedit: edit with custom filename For instance, Emacs allows to open file with special features enabled (AKA mode) based on the path/name of the file [1]. For such cases, use 'hg-histedit-XXX.txt' as filename pattern. [1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Choosing-Modes.html

ui: allow open editor with custom filename By default, editor will use temp file named after hard-coded pattern 'hg-editor-XXX.txt' which makes it impossible for extensions to use another filename if desired. Now the middle part of the pattern ('editor') can be changed by setting extra['prefix'].

help: make help deprecated mention the extension before this, you got an empty list of extensions, which was unhelpful

help: make listexts less confusing for deprecated exts Return an empty array instead of a heading and no items

patchbomb: rename email function I see no reason for the function not to be email ...

graphlog: rename glog function I see no reason for the function not to be glog ...

commit: preserve extra when amending with commit --amend The new extra propagation needs to be accounted for in cmdutil.amend, when checking for a no-changes fast-path.

graft: copy extra (except branch) when copying changesets

rebase: propagate extra dict from rebase source changeset This corrects extra propagation for the rebase command and the shelve command.

histedit: add examples

commands: add examples for 'addremove'

commands: add example for 'hg add'

extensions: refuse to load extensions if minimum hg version not met As the author of several 3rd party extensions, I frequently see bug reports from users attempting to run my extension with an old version of Mercurial that I no longer support in my extension. Oftentimes, the extension will import just fine. But as soon as we run extsetup(), reposetup(), or get into the guts of a wrapped function, we encounter an exception and abort. Today, Mercurial will print a message about extensions that don't have a "testedwith" declaring explicit compatibility with the current version. The existing mechanism is a good start. But it isn't as robust as I would like. Specifically, Mercurial assumes compatibility by default. This means extension authors must perform compatibility checking in their extsetup() or we wait and see if we encounter an abort at runtime. And, compatibility checking can involve a lot of code and lots of error checking. It's a lot of effort for extension authors. Oftentimes, extension authors know which versions of Mercurial there extension works on and more importantly where it is broken. This patch introduces a magic "minimumhgversion" attribute in extensions. When found, the extension loading mechanism will compare the declared version against the current Mercurial version. If the extension explicitly states we require a newer Mercurial version, a warning is printed and the extension isn't loaded beyond importing the Python module. This causes a graceful failure while alerting the user of the compatibility issue. I would be receptive to the idea of making the failure more fatal. However, care would need to be taken to not criple every hg command. e.g. the user may use `hg config` to fix the hgrc and if we aborted trying to run that, the user would effectively be locked out of `hg`! A potential future improvement to this functionality would be to catch ImportError for the extension/module and parse the source code for "minimumhgversion = 'XXX'" and do similar checking. This way we could give more information about why the extension failed to load.

run-tests: add --slowtimeout and use it for slow tests

serve: unify cmdutil.service() calls of commandserver and hgweb

hgweb: extract factory function of httpservice object The next patch will merge the cmdutil.service() calls of both commandserver and hgweb. Before doing it, this patch wipes out the code specific to hgweb from commands.serve().

hgweb: move httpservice object from commands module This avoids the deep import of hgweb.server at the commands module.

merge: move almost all change/delete conflicts to resolve phase (BC) (API) We have finally laid all the groundwork to make this happen. The only change/delete conflicts that haven't been moved are .hgsubstate conflicts. Those are trickier to deal with and well outside the scope of this series. We add comprehensive testing not just for the initial selections but also for re-resolves and all possible dirstate transitions caused by merge tools. That testing managed to shake out several bugs in the way we were handling dirstate transitions. The other test changes are because we now treat change/delete conflicts as proper merges, and increment the 'merged' counter rather than the 'updated' counter. I believe this is the right approach here. For third-party extensions, if they're interacting with filemerge code they might have to deal with an absentfilectx rather than a regular filectx. Still to come: - add a 'leave unresolved' option to merges - change the default for non-interactive change/delete conflicts to be 'leave unresolved' - add debug output to go alongside debug outputs for binary and symlink file merges

test-merge-changedelete.t: print out debugmergestate We're going to use this to verify the merge state in upcoming patches.

debugmergestate: also recognize change/delete conflicts in the merge state We're going to use this for tests in upcoming patches.

debugmergestate: print out null nodes as 'null' This is so much easier to read than a long string of zeroes, and we're going to have a lot more of these nodes once change/delete conflicts are part of the merge state.

test-merge-force.t: check .orig files separately We're going to soon compare the output of all the non-orig files before and after a resolve, and this makes that more convenient. The .orig files are obviously going to differ between the two.

merge.recordupdates: mark 'a' files as added unconditionally See the previous patch for why we do this.

merge: add a new action type representing files to add/mark as modified This is somewhat different from the currently existing 'a' action, for the following case: - dirty working copy, with file 'fa' added and 'fm' modified - hg merge --force with a rev that neither has 'fa' nor 'fm' - for the change/delete conflicts we pick 'changed' for both 'fa' and 'fm'. In this case 'branchmerge' is true, but we need to distinguish between 'fa', which should ultimately be marked added, and 'fm', which should be marked modified. Our current strategy is to just not touch the dirstate at all. That works for now, but won't work once we move change/delete conflicts to the resolve phase. In that case we may perform repeated re-resolves, some of which might mark the file removed or remove the file from the dirstate. We'll need to re-add the file to the dirstate, and we need to be able to figure out whether we mark the file added or modified. That is what the new 'am' action lets us do.

mergestate: add a cached property accessor for the local context This is going to be useful in an upcoming patch. We make this a public accessor because this is also going to be useful for custom merge drivers.

mergestate: raise exception if otherctx is accessed but _other isn't set We don't want to inadvertently return the workingctx (self._repo[None]).

pager: improve help for --pager= try to clarify how to enable/disable the pager

setup: remove unused py_modules argument to setup() It is never populated and is useless clutter.

test-merge-changedelete.t: add resolve --list output We're going to move change/delete conflicts to the resolve phase, and the resolve --list output is one of the things that will be important to test.

test-merge-changedelete.t: add a file with regular merge conflicts In upcoming patches we're going to move change/delete conflicts to the resolve phase -- it will be important to see how regular conflicts interact with change/delete ones.

filemerge: in ':prompt', use ':fail' tool rather than returning directly The ':fail' tool now knows to write out the changed side for change/delete conflicts. This has no impact right now but will make things better when we move change/delete conflicts in here.

filemerge: in ':fail' tool, write out other side if local side is deleted We do this because we don't want to modify the dirstate for failures, and don't just want to leave the file missing from disk. Plus it's more useful for the user if the changed side is written out -- it is easier to delete a file than to get it back via hg revert.

mergestate: explicitly forget 'dc' conflicts where the deleted side is picked Once we move change/delete conflicts into the resolve phase, a 'dc' file might first be resolved by picking the other side, then later be resolved by picking the local side. For this transition we want to make sure that the file goes back to not being in the dirstate. This has no impact on conflicts during the initial merge.