On 16/03/2011 19:00, Raymond Hettinger wrote: > I think devguide's suggested interbranch workflow introduces too much complexity for too little payoff. > The ability to merge between branches is a high payoff. *Having* to apply patches separately to all branches is also a nuisance, particularly given that easy merging between branches is one of the big advantages of a dvcs. Unfortunately if some developers decide they won't merge their changes that puts the burden of doing it on all the other developers (with more pain if the patches have been applied to different branches separately as developers merging their own changes now have to handle unrelated conflicts caused by someone else). What it should be possible for us to do is create scripts that will auto do the "reverse merge" for changes that shouldn't be forward ported. All the best, Michael Foord > 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 at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4