Eric Spishak-Thomas <emspishak@gmail.com> [Wed, 25 Mar 2020 17:44:08 -0400] rev 5210
evolve: fix some documentation grammar/typos
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Mar 2020 21:48:32 +0100] rev 5209
changelog: mention the recent evolve improvements
Manuel Jacob <me@manueljacob.de> [Sat, 21 Mar 2020 00:46:37 +0100] rev 5208
tests: merge two tests about split changesets
Because the removed test case is essentially already included in the
succeeding one, the tests are merged by removing the first.
Manuel Jacob <me@manueljacob.de> [Wed, 11 Mar 2020 16:05:53 +0100] rev 5207
evolve: support successors of ancestor of orphan with multiple roots
The previous code checked that the set of successors has a single root.
However, there’s no reason to require that in general.
Example:
o 6
|
o 5
|\
| o 4
| |
o | 3
|/
| * 2
| |
| x 1
|/
o 0
1 is obsoleted by 3, 4 and 6. We are considering the case when 2 gets evolved.
The roots are [3, 4] and the heads are [6]. Before the change, the user was
asked which destination to choose, but there was only one choice (6). After the
change, 6 is chosen as the destination.
Manuel Jacob <me@manueljacob.de> [Wed, 11 Mar 2020 16:04:06 +0100] rev 5206
evolve: support ancestor of orphan split with unrelated changeset in between
This is done by searching for roots and heads within the range delimited on
both sides by the target revs instead of just within the target revs.
Example:
o 5
|
o 4
|
o 3
|
| * 2
| |
| x 1
|/
o 0
1 is obsoleted by 3 and 5. We are considering the case when 2 gets evolved.
Before the change, both roots and heads were [3, 5]. The user was offered a
choice between 3 and 5 as the destination.
After the change, roots are [3] and heads are [5]. 5 is chosen as the
destination.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 11 Mar 2020 18:50:39 +0100] rev 5205
exchange: deal with empty obscommon
The case can happen, we better support it.
Anton Shestakov <av6@dwimlabs.net> [Fri, 20 Mar 2020 12:37:44 +0700] rev 5204
topic: compat with tr.changes[b'phases'], it's now a list
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 19 Mar 2020 20:09:18 +0530] rev 5203
topic: fix compatibility issues caused because of change in transaction API
In 36f08ae87ef687be53a59bd87376bcfbe4479205 in core mercurial, `_validator`
attribute to transaction class was removed and a dict was introduced. It added a
`addvalidator()` function to transaction class which can be used to register
multiple validator callbacks.
This updates the code to use `addvalidator()` when `_validator` attribute is not
present.