[Python-Dev] Hg: inter-branch workflow

[Michael Foord]

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