[Python-Dev] Merging flow

[Georg Brandl]

Benjamin Peterson schrieb:
> On Thu, Dec 4, 2008 at 12:52 PM, Eric Smith <eric at trueblade.com> wrote:
>> Christian Heimes wrote:
>>>
>>> Several people have asked about the patch and merge flow. Now that Python
>>> 3.0 is out it's a bit more complicated.
>>>
>>> Flow diagram
>>> ------------
>>>
>>> trunk ---> release26-maint
>>>       \->      py3k       ---> release30-maint
>>>
>>>
>>> Patches for all versions of Python should land in the trunk. They are then
>>> merged into release26-maint and py3k branches. Changes for Python 3.0 are
>>> merged via the py3k branch.
>>
>> Apologies if this has been discussed before. I looked but didn't see
>> anything.
>>
>> Given that at least 99% of the changes for the trunk will not get merged
>> into release26-maint, doesn't it make more sense to merge the other way?
>> That is, anything that gets checked in to release26-maint would potentially
>> be merged into trunk. That would remove the huge number of merge blocks that
>> will otherwise be required. Same fore py3k and release30-maint.

I've suggested that too; the counter-argument was that "most people don't
want to care in which branch to commit something".  I'm not too comfortable
with this argument as it implies a certain ignorance on the part of our
committers.  As Fred says, it wasn't discussed anyway.

Also, with svnmerge, it is not too late to change merging direction.

> I think the percentage is a bit lower than that. Also, we haven't been
> using blocking with the maintenance branch so far; svnmerge.py is just
> a convenience. (It generates commit messages and has a simpler
> interface than a simple "svn merge" command.)

I *did* use blocking with the 2.6 branch when I last merged a whole batch
of commits.  As you say, by using svnmerge without blocking we only get a
tool that can generate commit messages.  However, with blocking we get
something more valuable: we don't overlook backportable fixes anymore.

So: yes, blocking is more work, but it gives something important in return.

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.