run-tests: add --chg option to install and run tests using chg Because the temporary installation directory is shared between hg and chg, --chg is not allowed if --with-hg option is specified. Also, --chg option does not work on FreeBSD because "make" command is hard-coded. These limitations can be improved later. Almost all tests will fail with chg right now.

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

rebase: perform update through the 'update' command The update logic have grow more and more complicated over time (eg bookmark movement, new destination logic, warning on other head, etc). The rebase extension was reimplementing its own basic version of update to be used by 'hg pull --rebase'. We remove the custom code and use a combination of higher level functions. A test is added to check that the update is properly warning about other branch heads.

rebase: 'hg pull --rebase' now update only if there was nothing to rebase I recently discovered that 'hg pull --rebase' was also running an update. And it was running it in all cases as long as the update would move the working copy somewhere else... This felt wrong and it actually is. This 'update' call is introduced in 92455c1d6f83. In that commit the intent is very clear. The update should happen only when there was nothing to rebase. The implementation did not check if a rebase was performed because, at that time, rebase would always leave you on the top most changeset. Being on that top most changeset result in a no-op update and the step was skipped. However 9c78ed396075f changed rebase behavior to preserve the working copy parent, so if we are not on a head at pull time, the code performs both a rebase and an update. This changeset introduce a test for this case and restore the intended behavior. There are other issues with this custom update code but they will be addressed in later changeset (eg: own destination logic, lack of heads warning). I'm not super happy with the explicitly comparison 'rebase(...) == 1' but a later series will have a cleaner way to handle it anyway (while making 'rebase' pick its default destination like 'merge').

filectx: replace use of _filerev with _filenode _filerev depends on the filelog implementation using revlogs and linkrevs. Alternative implementations, like remotefilelog, do not have rev numbers, so this call fails. Replacing it with _filenode means it doesn't rely on rev numbers, and doesn't cost anything extra, since _filerev is using _filenode under the hood anyway.

verify: extract "manifest" constant into variable The "manifest" label that's used in error messages will instead be the directory path for subdirectory manifests (not the root manifest), so let's extract the constant to a variable already to make future patches simpler.

verify: use similar language for missing manifest and file revisions When a changeset refers to a manifest revision that's not found in the manifest log, we say "changeset refers to missing revision X", but when a manifest refers to file revision that's not found in the filelog, we say "X in manifests not found". The language used for missing manifest revisions seems clearer, so let's use that for missing filelog revisions too.