On Thu, 17 Mar 2011 00:20:26 +0100, Antoine Pitrou <solip...@pitrou.net> wrote: > > I think devguide's suggested interbranch workflow introduces too > > much complexity for too little payoff. > > > > If I need to make a fix to 3.2, I can't just fix it. I would need > > to also merge the changeset into 3.3 and then revert it, and then > > commit both. There is not much payoff to this style. It brings > > back the ghost of svnmerge but it much more restrictive: > > Well, you might not have liked svnmerge, but most other devs preferred > using it instead of porting patches by hand. > I think the same argument goes for "hg merge".
+10. And I've done quite a few commits here at the sprints. I'd *really* hate to have had to patch each branch by hand. If I'd had to do that I'm sure I wouldn't have bothered with 3.1. As it is, once I applied the patch once to 3.1, doing the merges was a piece of cake. Patching 2.7, on the other hand, is a pain. Dealing with a null merge when someone else has committed between the time I started the merge dance (I always pull just before I start that) and the time I push is not that hard either. It pretty much amounts to having to do an additional set of merges. (In my case I do a strip and restart my merge dance, but I'm not sure I should recommend that since altering history is considered dangerous :) Even this week, with all the commit activity surrounding the sprints, I have only had to deal with a push race twice out of 16 patches. I expect to hit it only very rarely in normal development work. Alternatively, Ezio at least follows the policy of doing a pull -u/commit/push in the first branch, and then doing pull -u/merge/push in the next branch. You are even less likely to hit a push race by following that technique, since the time between the pull -u and the push is minimized. -- R. David Murray www.bitdance.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com