run-tests: add --with-chg option to run tests using chg Unlike --with-hg=/path/to/chg, this option allows us to start and clean up command servers in isolated environment. And we can specify the hg command as well as the chg command.

destutil: add more precise error classes for destmerge Having exception classes more precise than 'Abort' will allow us to properly catch "nothing to rebase" situations when we will be using 'destmerge' in rebase.

destutil: allow to disable the "on head check" in destmerge 'hg merge' refuses to pick a default destination if the working copy is not on a head. This is a very sensible default for 'hg merge' but 'hg rebase' should work in this situation. So we introduce a way to disable this check. It will soon be used by rebase.

destutil: allow to specify an explicit source for the merge We can now specify from where the merge is performed. The experimental revset is updated to take revisions as argument, allowing to test the feature. This will become very useful for pick the 'rebase' default destination. For this reason, we also exclude all descendants from the rebased set from the candidate destinations. This descendants exclusion was not necessary for merge as default destination would not be picked from anything else than a head. I'm not super excited with the current error messages, but I would prefer to delay an overall messages rework once 'hg rebase' is done getting a default destination aligned with 'hg merge'.

destutil: remove current head from list of candidates early While 'hg merge' will refuse to pick a default destination if the working copy is not on a head, this will be a common and valid case for rebase. In this case, we will need to exclude from the candidate destination all descendants from the rebased set. We make a step forward in that direction by removing parents of the working copy from the candidate destinations instead of manually filtering the working copy parent at the end of the process. This will make the extra step of filtering descendant much simpler in a future changeset.

destutil: add an 'action' layer to the destmerge message dictionary We'll introduce messages for 'rebase' soon, so we introduce a way to select a message based on the action being performed.

rebase: extract rebaseset and destination computation in a function The whole rebase function is gargantuan and this computation is almost 100 lines long. We extract it in a dedicated function as it is independent from the rest of the rebase code. Having it in its own function will make it easier to rework the default destination logic.

tests: have a more elaborated test for _destrebase The previous repo had a single lineage and a single head, pretty boring for rebase related testing.

histedit: break _histedit function into smaller pieces We add _getgoal, _validateargs. This is a part of bigger effort to refactor histedit. Initial steps are to break _histedit function into smaller pieces which will supposedly be more understandable. After this is done, I will have a better understanding of how histedit works and apply that to fix issue4800.

histedit: break _histedit function into smaller pieces (add _continueaction) This is a part of bigger effort to refactor histedit. Initial steps are to break _histedit function into smaller pieces which will supposedly be more understandable. After this is done, I will have a better understanding of how histedit works and apply that to fix issue4800.

histedit: break _histedit function into smaller pieces (add _newaction) This is a part of bigger effort to refactor histedit. Initial steps are to break _histedit function into smaller pieces which will supposedly be more understandable. After this is done, I will have a better understanding of how histedit works and apply that to fix issue4800.

histedit: break _histedit function into smaller pieces (add _editplanaction) This is a part of bigger effort to refactor histedit. Initial steps are to break _histedit function into smaller pieces which will supposedly be more understandable. After this is done, I will have a better understanding of how histedit works and apply that to fix issue4800.

histedit: break _histedit function into smaller pieces (add _abortaction) This is a part of bigger effort to refactor histedit. Initial steps are to break _histedit function into smaller pieces which will supposedly be more understandable. After this is done, I will have a better understanding of how histedit works and apply that to fix issue4800.

automv: new experimental extension Automatically detect moves and record them at commit time. This extension was originally developed at https://bitbucket.org/facebook/hg-experimental

match: override 'visitdir' in subdirmatcher The manifest.manifest class has a _treeinmem member than one can manually set to True to test that the treemanifest class works as a drop-in replacement for manifestdict (which is mostly a requirement for treemanifest repos to work). However, it doesn't quite work at the moment. These tests fail: test-largefiles-misc.t test-rebase-newancestor.t test-subrepo.t test-subrepo-deep-nested-change.t test-subrepo-recursion.t All but test-rebase-newancestor.t fail because they trigger calls to subdirmatcher.visitdir(), which tries to access a _excluderoots field that does not exist on the subdirmatcher. Let's fix that by overriding visitdir() in a similar way to how matchfn is overridden, i.e. by prepending the directory before calling the superclass method.

run-tests: remove useless "failed" flag from addOutputMismatch() It never be set to True.

tests: load json with no fallback The json module should be available in Python 2.6 or newer.

config: drop progress extension from sample hgrc as it is in core now

shelve: suggest the correct tool to continue (not unshelve) Suggest committing (or whatever the current activity is), via wrongtooltocontinue which uses howtocontinue.

histedit: suggest the correct tool to continue (not histedit) Suggest committing (or whatever the current activity is), via wrongtooltocontinue which uses howtocontinue.

rebase: suggest the correct tool to continue (not rebase) Suggest committing (or whatever the current activity is), via wrongtooltocontinue which uses howtocontinue.

graft: suggest the correct tool to continue (not graft) Add test coverage for graft --continue without starting. Suggest committing (or whatever the current activity is), via wrongtooltocontinue which uses howtocontinue.

cmdutil: provide a way to report how to continue checkafterresolved allows Mercurial to suggest what command to use next. If users try to continue the wrong command, there wasn't a good way for the command to suggest what to do next. Split checkmdutil into howtocontinue and checkafterresolved. Introduce wrongtooltocontinue which handles raising an Abort with the hint from howtocontinue.

hg: make cachedlocalrepo cache appropriate repoview object Before this patch, 'cachedlocalrepo' always caches "visible" repoview object, because 'cachedlocalrepo' uses "visible" repoview returned by 'hg.repository()' without any additional processing. If the client of 'cachedlocalrepo' wants "served" repoview, some objects to be cached are discarded unintentionally. 1. 'cachedlocalrepo' newly caches "visible" repoview object (call it VIEW1) 2. 'cachedlocalrepo' returns VIEW1 to the client of it at 'fetch()' 3. the client gets "served" repoview object by 'filtered("served")' on VIEW1 (call this "served" repoview VIEW2) 4. accessing to 'repo.changelog' implies: - instantiation of changelog via 'localrepository.changelog' - instantiation of "filtered changelog" via 'repoview.changelog' 5. "filtered changelog" above is cached in VIEW2 6. VIEW2 is discarded after processing, because there is no reference to it 7. 'cachedlocalrepo' returns VIEW1 cached at (1) above to the client at next 'fetch()' 8. 'filtered("served")' on VIEW1 at the client side creates new "served" repoview again, because VIEW1 is "visible" (call this new "served" repoview VIEW3) 9. accessing to 'repo.changelog' implies instantiation of filtered changelog again, because "filtered changelog" is cached in VIEW2 at (5), but not in VIEW3 currently used 10. (go to (7) above) As described above, "served" repoview object and "filtered changelog" cached in it are discarded always, even if the repository itself hasn't been changed since last access. For example, in the case of 'hgweb_mod.hgweb', "newly caching" occurs, when: - all cached objects are already assigned to another threads (in this case, repoview is created in 'cachedlocalrepo.copy()') - or, stat of '00changelog.i' is changed from last access (in this case, repoview is created in 'cachedlocalrepo.fetch()') once changes are pushed via HTTP, this always occurs. The root cause of this inefficiency is that 'cachedlocalrepo' always caches "visible" repoview object, even if the client of it wants another view. To make 'cachedlocalrepo' cache appropriate repoview object, this patch adds additional filtering on the repo object returned by 'hg.repository()'. It is assumed that initial repoview object should be already filtered by expected view. After this patch: - 'filtered("served")' on VIEW1 at (3)/(7) above returns VIEW1 itself, because VIEW1 is now "served", and - VIEW2 and VIEW3 equal VIEW1 - therefore, "filtered changelog" is cached in VIEW1, and reused intentionally