[Python-Dev] Backport troubles with mercurial

[Stephen J. Turnbull]

Amaury Forgeot d'Arc writes:

 > Which precise steps do you take [to cherrypick with export/import]?

hg export -r $CHERRY .tmp.patch
xemacs .tmp.patch
;; Move to end of log message, type "Cherry-picked from: ", then
;; C-u M-! hg id -i -r $CHERRY RET C-x C-s C-x C-c>
hg import .tmp.patch

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

CHERRY can be a tag, revno, or other alias for the revision.  You may
want to add other identifying information with additional arguments to
"hg id", but "hg id -i" give the canonical ID.  You may want to fix up
committer and date using the -u and -d arguments to hg import.

 > How much typing or manual copy/paste is required for this very simple case?

For the simple case, the above can be scripted, and the script takes
one argument, CHERRY.  It would not be hard to automate adding the
cherry-pick notice.

 > Can you do the merge in less than 10 minutes?

If no conflicts, sure, no problem.  Probably about 30 seconds,
including adding the cherrypicked revid to the log message.  With a
script, maybe 1 second.

If there are conflicts, it depends on the complexity of the conflicts.
I can imagine this could get hairy with the export | import method and
a megapatch, but I've never had to deal with that in practice.  This
is one reason why it's recommended that feature branches be
constructed of multiple, clearly separated patches.  (This may be
difficult to do for complex changes, but it's usually a reasonable
goal.)

 > And finally the biased question:
 > can you find one improvement over the current situation with svn?

No, I can't find just one.  How many are you willing to read?<wink>

svn has the advantage (and yes, it's a big one) that developers are
already used to it.  Otherwise, everything goes in favor of any of the
dVCSes.

 > - even if there was one, there is the problem of changes
 >   specifically made for 2.7 that make no sense in py3k.

This is a problem with the committer, not with the VCS.  Such changes
belong in a separate commit, with an appropriate log entry, in *any*
version control system.  If that is done, there's no problem, you just
don't cherrypick that change.

 >   You'd have to perform a "dummy merge" to py3k which has the
 >   disadvantage of cluttering the py3k change log.

I don't see why.  Such dummy merges can help only if you are going to
rely on hg merge.  But you are not going to be merging 2.x and 3.x.

True, some patches from the maintenance branch won't be applied to the
trunk.  This is expected, and it is a problem that needs to be solved,
probably with a tool like svnmerge, which will do a dummy merge or a
revert commit to exclude that revision from any future merge to trunk.
Therefore, if we change our minds, it's perfectly safe to cherrypick.
Any conflicts that occur are real conflicts, not merge artifacts.

 >   And think of the horror if someone forgets this dummy merge.

What horror?  By cherry-picking you have assumed responsibility for
managing future cherry-picks from that source to that target in any
case; you can no longer expect reliable help from Mercurial.  It's not
at all clear to me that a dummy merge could accomplish anything useful,
especially in the case of 2.x <-> 3.x cherry-picks.

If on the other hand you're thinking of the merge-from-maint-branch
case, as I say this is a problem that needs solving anyway, just as it
did with svn.