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