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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
