[Python-Dev] Backport troubles with mercurial (original) (raw)

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?)

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