[Python-Dev] Merging flow

Brett Cannon brett at python.org
Thu Dec 4 22:49:40 CET 2008


On Thu, Dec 4, 2008 at 13:21, Georg Brandl <g.brandl at gmx.net> wrote:
> 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.
>

That would make the rule for choosing which branch to first commit to
be the one with the smallest version:

2.6 -> trunk -> 3.0 -> py3k

That seems reasonable to me since that is really what the code
branching is and how I suspect we will do things with a DVCS.

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

If changing it to be like above is not an issue then I vote for the change.

>> 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.

The other perk of this ordering is you should be able to place a
single block along the chain where the patch should stop and
potentially be done with the merges if you are in a rush. That way
people who do mass merges can just sequentially merge and not worry
about where a patch should stop.

-Brett


More information about the Python-Dev mailing list