[Python-Dev] Backport troubles with mercurial

Amaury Forgeot d'Arc amauryfa at gmail.com
Wed Dec 29 01:13:13 CET 2010


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.

"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.

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

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)
At the moment, I feel that mercurial just cannot work for core Python
development.

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

Thanks for your help,

-- 
Amaury Forgeot d'Arc


diff -r 2777ae4d10d9 Lib/test/test_contextlib.py
--- a/Lib/test/test_contextlib.py       Tue Dec 28 22:14:34 2010 +0100
+++ b/Lib/test/test_contextlib.py       Wed Dec 29 00:08:18 2010 +0100
@@ -26,6 +26,7 @@
             state.append(x)
         self.assertEqual(state, [1, 42, 999])

+    @support.cpython_only
     def test_contextmanager_finally(self):
         state = []
         @contextmanager
@@ -36,10 +37,10 @@
             finally:
                 state.append(999)
         with self.assertRaises(ZeroDivisionError):
-            with woohoo() as x:
+            with woohoo() as y:
                 self.assertEqual(state, [1])
-                self.assertEqual(x, 42)
-                state.append(x)
+                self.assertEqual(y, 42)
+                state.append(y)
                 raise ZeroDivisionError()
         self.assertEqual(state, [1, 42, 999])
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101229/17b081a4/attachment.html>


More information about the Python-Dev mailing list