On Dec 4, 2008, at 1:52 PM, Eric Smith wrote:
Apologies if this has been discussed before. I looked but didn't see anything.
Probably has, just 'cause everything has been discussed before.
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.
The directions of merges were established in the past at some point. Though they feel wrong (at least to you and me), the direction is what it is. I'd asked about the direction mostly because I can never remember after time away from working on the Python tree. That said, don't let Python's decision on the direction keep you from managing your own projects the right way. :-) In fact, it's reasonable to fix bugs on the release26-maint branch, migrate the patch to the trunk, and then use svnmerge.py from there to propagate the changes. -Fred -- Fred Drake <fdrake at acm.org>