[Python-Dev] Backport troubles with mercurial

[Georg Brandl]

Am 29.12.2010 01:13, schrieb Amaury Forgeot d'Arc:
> Hello,
> 
> The PyPy project recently switched from svn to mercurial. Since this day I have some
> difficulties to perform simple tasks, and my questions did not receive
> satisfying answers.
> 
> I was sure the Python project would have the same issues;
> so I started from the repositories in http://code.python.org/hg/ and tried simple
> merges between Python versions.
> I would like several people to try the same example, and tell how they handle it.
> I'm new to mercurial, and I may have missed something important!
> 
> 
> Let's say you have to do the simple change shown in the diff below,
> and want to "fix" the the 3 usual versions: py3k, release31-maint, release27-maint.
> The diff was made against py3k.
> 
> How would you do it with Mercurial? Please try to do it for real!
> 
> "hg merge" is not the correct command: it merges whole branches, a change
> comes with all its ancestors. What we want is to "cherry-pick" a single change.
> 
> "hg transplant" fails to apply the change to release31-maint because
> of a tiny conflict (in the diff context!) that leaves you with an ugly
> "hunks FAILED" and a .rej file you have to parse and apply by hand.

Yes, this has been an irritation to me as well.  It's probably not so hard for
a Mercurial coredev to change transplant into generating inline conflict markers
though.

BTW, we would apply the diff in release31-maint and then "hg merge" it to py3k.
transplant still applies to 2.7 though.

> "hg transplant" seems to succeed in release27-maint,
> but the test fails to run because "support" should be changed to "test_support".
> The change is already committed - to fix it another changeset is needed.
> This does not look clean to me: both changesets will be pushed to the repository,
> and diff review (on the python-checkins mailing list) is almost impossible.

Right.  Seems to me transplant should get a command-line switch that always goes
into break-and-continue mode, where the commit is only made after calling
"hg transplant --continue".

> Furthermore, "hg transplant" does not keep track of integrations.
> There is a "transplants" file, but it stays in my local clone.

You're wrong, it does keep track of integrations in the commit metadata.  The
only thing that's clone-local is the transplants cache file.  Sadly, transplant
only checks against this file, but it is very easy to write a hook that keeps
it up to date; I've already done that work.

> Faced with a similar case in pypy, we finally manually copied the files
> between directories... and the fastest with our example is probably
> to do the change manually in all three directories.
> 
> There is surely a better way to work with maintenance branches!
> PEP374 suggests to first modify the oldest release, but this does not
> seems right to me (I have three reasons in mind)

Would you care to explain those?

> At the very least before the migration we need precise use cases like this
> and recipes for common cases.

Which is what we'll certainly get once we have the test repo and Brett is
rewriting the dev guide.

Georg