Hello, > 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". > (if we look at the tracker, you can see that it is very common for the > resolution on different branches to be done at different times) That's not my experience. Often, when the resolution on other branches is deferred, it means the committer has actually forgotten about it. It doesn't really make sense in practice to defer such resolution: you want the issue to be fresh in your head when committing patches; you don't want to have to context-switch everything back into your head, read the discussion again, try to remember the subtleties, etc. Doing the different branches at different times makes you lose more of your time, cumulated, and also increases the risk of doing something wrong. > As far as I can tell the only benefits to the cross-linking are that it > reduces the chance that a patch will be applied to an older branch but not > forward ported. Well, no. The main benefit is ease of merging, by definition ;) Regards Antoine. _______________________________________________ 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
