Dirkjan Ochtman schrieb: > On 05/04/2009 12:27, Antoine Pitrou wrote: >> There's also the issue of how we adapt the current workflow of "svnmerging" >> between branches when we want to back- or forward-port stuff. In particular, >> tracking of already done or blocked backports. > > Right. The canonical way to do that with Mercurial is to commit patches > against the "oldest" branch where they should be applied, so that every > stable branch is a strict subset of every less stable branch.
That's what I do as well in Sphinx. It works fine there, but there are two issues if you want to apply it to Python: * As Antoine said, trunk and py3k are very different. Merging would still be possible, but confusing. * Our current trunk/maint branches will have completely different commits, so pulling (e.g.) from 2.6 into trunk won't work. So I'd be in favor of a solution like the following: * Once 2.7 and 3.1 are final, create their maint branches as "real" Hg branches, so that for each pair committing to maint and pulling into trunk works. * For the 2->3 merging, use transplant (optionally with the mentioned feature of keeping track what was already transplanted and blocked). Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. _______________________________________________ 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
