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: * it is pretty much required for every patch on a non-default branch * you have to decide in advance how far it should be backported because only forward porting is supported * it means you can't just fix one branch without having also decided how the change should be applied to other branches (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) I think we would be better off treating the branches as independent. If I need to apply a patch to two of them, that's what I would do (in any order, at any time, or with or without modifications). 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. I've been enjoying most of my experiences with mercurial, but as soon we start needing rebases, null merges, merges followed by null reverts, then we might as well be using git. The version control system is supposed to make our lives easier, not introduce more workflow requirements. I don't think the more complex workflow if worth it. Mercurial is very user friendly right out of the box will simple commands. But as soon as you require the branches to be inter-linked, you've made it much more difficult to get simple checkins done. Raymond _______________________________________________ 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
