FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 22 Jan 2016 21:41:59 +0900] rev 1594
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.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 23 Jan 2016 06:18:01 +0900] rev 1593
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.
Shusen LIU <liushusen@fb.com> [Tue, 26 Jan 2016 15:42:01 -0800] rev 1592
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'
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 30 Jan 2016 16:53:12 +0100] rev 1591
test: add extra expected output
(I forgot to amend...)
Jeroen Vaelen <jeroen@fb.com> [Fri, 22 Jan 2016 19:16:38 +0000] rev 1590
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.
Laurent Charignon <lcharignon@fb.com> [Sun, 17 Jan 2016 16:55:40 -0800] rev 1589
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.