merge stable into default

url: update url to point to the latest hosting The documentation and various packaging were out of date.

tests: add head warning messages Core gained a warning about other head on the same branch. This impact our tests.

split: fix wording of documentation for --rev option

merge with stable

Added tag 5.3.0 for changeset bd59cc2ee203

merge with strange other head on stable

prepare version 5.3.0

evolve: update testedwith statement We have carefully testing with Mercurial form 3.4 to 3.7

Readme: mention fix for issue4950

merge with new stable through 3.5 and 3.6

tests: register expected difference for Mercurial 3.4

merge with stable through 3.6

readme: mark feature only available in 3.7 as such

Merge with stable, updating tests output Notable change: - We do not support evolving merge before 3.7 - We don't support inhibit/direct-access

readme: point to mercurial-scm.org instead of selenic.com

merge with stable (Mercurial 3.7 is out)

tests: register expected difference for Mercurial 3.6

tests: register expected difference for Mercurial 3.5

test: adapt to 3.6 help changes

evolve: make split respect rev args passed without --rev or -r Currently, if one runs `hg split .` or `hg split`, it will fail with an exception. This happens becuase we only expect revision args to be passed as --rev/-r ones and don't treat unnamed args properly or add default values if no args are provided.

evolve: write our own custom evolvestate file Since for ever, we were using 'graftstate' to record the node currently being evolve and allow 'hg evolve --continue' we now move to our on 'evolvestate' file. This remove and issue with 'hg summary' listing interrupted evolve as graft. This also open the way for storing more data into that file and allow proper --abort and --continue of the whole evolve operation (and not just the last one). The whole thing is very hacky but at least there is some progress. Thanks goes to Shusen Liu for initiating this work.

readme: update readme for issue 4966

test: back hash change from 'extra' content change out The changesets 13701c3fed9c, 3e907ff1981f and 54394d2aaf5e were introduced to handle a change to the way extra were carried out by various command in core. This had to be backout for 3.7.1 as is broken multiple third party extension. We backout the test update as a result. Core changesets performing the backout: ce9696193175::b698abf971e7

evolve: close transaction if conflict is detected in relocate (issue4966) Before this patch, transaction is aborted, if conflict is detected at merging while "hg evolve". Since 8f2ff40fe9c9 (or 3.6) of Mercurial, aborting transaction discards all dirstate changes inside transaction scope for "transactional dirstate" (see below wiki page for detail about it). https://mercurial.selenic.com/wiki/DirstateTransactionPlan Therefore, just aborting transaction causes unchanged (and unexpected) dirstate, even though subsequent commands require dirstate changes while "hg evolve". To keep dirstate changes while "hg evolve", this patch closes current running transaction, if conflict is detected in relocate(), even though exception is raised as usual. Even though "save dirstate and restore it after aborting transaction" like shelve._aborttransaction() of Mercurial can also solve this issue, this patch chose closing transaction for similarity with failure for conflict at "hg unshelve". In addition to it, closing transaction can keep any previous (implicit) changes. In newly added test, there is an additional ancestor revision, which "will be evolved safely". It is used to examine whether failure for conflict doesn't discard already relocated revision(s) while "hg evolve". It is fact for current implementation that "hg evolve" relocates each revisions in separated transactions and already relocated ones are never discarded, even if subsequent relocation fails. Though, this examination is useful to detect unintentional regression in the future.

evolve: remove meaningless transaction nesting Before this patch, functions below nest transaction scope, even though they are invoked only inside a transaction scope created at _solveone(). - _solvebumped() - _solvedivergent() - relocate() via _solveunstable() or _solvebumped() Transaction nesting is useful for localizing "success" (e.g. one scope per commit inside wider scope for multiple committing). But such nesting is redundant for _solveone(), because there is no code path, which causes failure after successfully closing inner transaction(s). In addition to it, this nesting makes it complicated to close current transaction successfully with exception raising inside inner scope, like "hg shelve" at detection of conflicts. "tr.close()" is required at each outer scopes for such case. To remove meaningless transaction nesting, this patch replaces repo.transaction() in functions above by repo.currenttransaction(). This reuses transaction created at _solveone(). This patch also adds 'assert tr' after getting current running transaction, to avoid invocation of functions above without transaction.

evolve: extract logic to new method _evolvemerge This patch introduces a new method _evolvemerge to merge orig to dest in relocate method. This simplifies the code of the method relocate and allows us to re-use it later in the scope of the rework of 'hg evolve --continue'

test: add extra expected output (I forgot to amend...)

inhibit: make bookmark -D work with a list of bookmarks `hg bookmark -D` was not accepting a list of bookmarks. This behavior was inconsistent with the behavior of `hg bookmark -d`, which does accept multiple bookmarks.

touch: prompt the user for what to do with the revived changeset This patch improves our interface for reviving changesets. This patch makes touch not assume that the user wants to create divergence by default and gives a prompt instead. The prompt is skipped for changeset that have no living successor as no divergence would be created by reviving them anyway. To restore the previous behavior, one should now use the --allowdivergence flag. The prompt looks like: [10] <description> reviving this changeset will create divergence unless you make a duplicate. (a)llow divergence or (d)uplicate the changeset? a In further patches we will want to add one more choice to that prompt, for example having a marker between the old and revived nodes but no divergence displayed on the UI.