Anton Shestakov <av6@dwimlabs.net> [Tue, 18 Jun 2019 17:17:31 +0800] rev 4689
evolve: orphans that evolve into nothing don't need successors (issue5967)
When continuing to solve an orphan that created no changes (i.e. clean wdir),
_completeorphan() used to create an obsmarker that said that the result of that
orphan evolution is the currently checked out changeset. That's not a correct
obsmarker, because all of the orphan's changes were dropped and so it had no
effect on the currently checked out changeset.
This is an issue that has only existed when --continu'ing evolve, that's why
the fix touches _completeorphan(), but not _solveunstable(). This fix is
adapted from a similar "if node is None" block in _finalizerelocate().
Anton Shestakov <av6@dwimlabs.net> [Sat, 22 Dec 2018 18:31:32 +0800] rev 4688
tests: demonstrate obsmarker creation after discarding conflicting changes
Continued evolve creates an incorrect obsmarker that says 2 is a successor of
1. It's incorrect because 1 was dropped as it created no changes to commit
(after conflict resolution that discarded its changes).
If evolve does the same thing in one go (e.g. just by using --tool :local and
without subsequent need to continue) the obsmarker is correct.
Anton Shestakov <av6@dwimlabs.net> [Fri, 07 Jun 2019 18:14:48 +0800] rev 4687
pick: remove transaction on the whole command (issue6037)
At its core, pick is a pretty straightforward and well-behaving command, it
uses functions already in core hg, it checks that wdir is clean and that
changeset to pick is not public, it checks if there happen to be merge
conflicts and can be --continue'd later, etc.
It is very similar to graft in core (it also uses mergemod.graft function), but
it obsoletes the original changeset. However, graft does not experience this
incorrect behavior from issue 6037.
What happens in the test case for this issue when we pick a revision that
touches both "a" and "b": mergemod.graft() takes the original changeset and
tries to apply it to the wdir, which results in "b" being marked as newly added
and ready to be committed, "a" updated with the new content and being marked as
modified, but "a" also has conflicts. Pick correctly notices this and saves its
state before asking for user intervention. So far so good. However, when the
command raises InterventionRequired to print a user-facing message and exit
while being wrapped in repo.transaction() context manager, the latter partially
undoes what mergemod.graft() did: it unmarks "b" as added. And when user
continues pick, "b" is therefore not tracked and is not included in the
resulting commit.
The transaction is not useful here, because it doesn't touch wdir (it's still
dirty), it doesn't remove pickstate (and other commands will refuse to work
until pick --abort or --continue), it just makes "b" untracked.
The solution is to use repo.transaction() only to wrap code that writes data to
hg store in the final stages of the command after all checks have passed and is
not expected to fail on trivial cases like merge conflicts. For example,
committing the picked changeset. But since pick uses repo.commit() for that,
and because that function already uses a transaction, wrapping it in another
transaction doesn't make sense.
Anton Shestakov <av6@dwimlabs.net> [Sun, 23 Dec 2018 01:02:36 +0800] rev 4686
tests: demonstrate hg pick forgetting files after conflicts
This test currently passes to show that pick is behaving incorrectly.
Anton Shestakov <av6@dwimlabs.net> [Thu, 13 Jun 2019 13:27:26 +0800] rev 4685
packaging: follow hg's supported python version (>= 2.7)
"Mercurial 4.3 and newer require Python 2.7." (From
https://www.mercurial-scm.org/wiki/SupportedPythonVersions)
Also add X- prefix, because that's the correct form, apparently.
This line can also be removed in future, since "When Debian supported multiple
Python versions, X-Python-Version was used, but it is obsolete now as no
supported Debian release supports anything other than python2.7." (From
https://wiki.debian.org/Python/LibraryStyleGuide)
That page also mentions "X-Python3-Version".
Anton Shestakov <av6@dwimlabs.net> [Thu, 13 Jun 2019 13:19:44 +0800] rev 4684
packaging: require hg 4.5 also for usage, not just for building
Philippe Pepiot <philippe.pepiot@logilab.fr> [Tue, 11 Jun 2019 10:04:11 +0200] rev 4683
packaging: require mercurial >= 4.5
Otherwise building the doc package fails with:
(third party extension evolve requires version 4.5 or newer of Mercurial; disabling)
Exception occurred:
File "/usr/lib/python2.7/dist-packages/mercurial/help.py", line 624, in help_
raise error.Abort(msg, hint=hint)
Abort: no such help topic: evolve