Re: [Monotone-devel] Automerging

[Daniel Carosone]

On Tue, May 22, 2007 at 10:16:01PM +1000, William Uther wrote:
>    Option ii) I could start a new branch for my own version of the code, 
>  develop on the main branch, and propagate the changes across.  This means I 
>  don't get to develop with my local changes (which is both a positive and a 
>  negative).  It also means I have to keep propagating.

This is what I do, and I don't see the drawbacks.  It seems to me to
be pretty much exactly what branches are for, and I like that I get to
choose when and how they propagate/merge.  If in doubt, use another branch.

The issues here are those that policy branches will attempt to
address: branch namespace issues, accidental syncs of too much info,
etc.

>    Change i) St?phane's idea of a multiple checkout.  I make a branch for my 
>  local changes.  I then do a multiple checkout of my branch and the trunk.  
>  The auto-merging means I get the best of both worlds.  Committing is 
>  interesting.  (You'd have to take the diffs against the auto-merged branch, 
>  use OT theory to move that patch back before the auto-merge, and then 
>  commit.  That shouldn't be too bad as you can always complain to the user.)

It's the interesting commit issue that's the problem.  Better IMHO to
decompose into several (recoverable) steps with separate branches and
props.

>    Change iv) Add an "auto-propagate" ability that propagates any new revs on 
>  one branch onto a second one.  This gets "interesting" if there are multiple 
>  heads about.

Maybe interesting and worth exploring further, along with a collection
of similar "smart" jumbo commands that do several steps in one (eg,
commit-pull-merge-sync-update).

One of the basic pieces that might be useful for such a thing is for
the whole lot to be done as one transaction.  Eg, in your case where
there are multiple heads on the target branch, it could try merging
those heads, and then merging for the propagate - but if the propagate
failed the merge would also be rolled back.  That would help avoid
risk of some surprise side-effects.

--
Dan.

pgpExDB9pCCLu.pgp
Description: PGP signature