g.brandl at gmx.net
Sun Apr 5 14:46:12 CEST 2009
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
* For the 2->3 merging, use transplant (optionally with the mentioned
feature of keeping track what was already transplanted and blocked).
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.
More information about the Python-Dev