On Thu, Dec 4, 2008 at 13:21, Georg Brandl <g.brandl@gmx.net> wrote:
Benjamin Peterson schrieb:
On Thu, Dec 4, 2008 at 12:52 PM, Eric Smith <eric@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