[Python-Dev] Backport troubles with mercurial

R. David Murray rdmurray at bitdance.com
Wed Dec 29 16:25:10 CET 2010

On Wed, 29 Dec 2010 23:12:28 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> worked for me the one time I tried it, IIRC.  Now I use patch queues,
> and avoid cherry-picking as much as possible.  (Avoiding cherry-pick
> is not going to be possible for 3.x <-> 2.x porting, of course, but in
> many cases there a simple patch application is not going to work at
> all, anyway.  Should be relatively rare, no?)


We merge bug fixes to 2.7 on a routine basis.  It is the rule rather
than the exception, by a long shot.  (Features of course only go into
trunk...but those are irrelevant to this conversation, since there's no
requirement to merge them anywhere...as are bug fixes we choose not to
backport, since those don't go into the Python3 maint branch either.)

Some such merges apply cleanly, many more have only a few conflicts
requiring only trivial tweaks, which are made easy by the in-line merge
conflict markers.  A few require re-engineering of the patch, and of
course it is a bit of a pain with svnmerge to deal with the ones where
the target file names have changed (but again, there aren't that many
of those). [*]

So, since we are going to be maintaining 2.7 for a while, this is
a workflow problem that we *must* solve to make the hg transition
worthwhile.  I have no doubt that we will, but I also have no doubt we
need to *solve* it, not just wave our hands.  Many thanks to Georg and
Djirkan for working on the problem(s).

R. David Murray                                      www.bitdance.com

[*] I'm speaking of stdlib changes, which is what I do, but I suspect
the situation is similar for the C code, and certainly the fact that bug
fixes backported to Python3 maint are routinely backported to 2.7 is true.

More information about the Python-Dev mailing list