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