[Monotone-devel] zipper merges (was: Merge frustration)

[Daniel Carosone]

On Wed, Jun 21, 2006 at 03:02:53PM +0200, Wim Oudshoorn wrote:
> monotone: misuse merge of 's/S/ChangeLog' : xxxx -> xxxx vs xxxx failed.
> 
> So now I lost all my merge work up to that point.  Grr.

Yes. I know this frustration, too.  I, too, still like the concept of
a database-merge, in spite of this.

> If version control systems are about not loosing work etc. 
> This behaviour seems wrong.  I need all me attention for the actual merge.

The points you raise are valid, and have been discussed by others well
enough.  Let me add another option you might want to consider that you
can do now, and that the rest of the group may want to consider as a
use case for further UI improvement too.

You have a situation where you're trying to merge two paths of
development that diverged some time ago and which, for one reason or
another, haven't had the series of intermediate smaller merges that
you might otherwise have expected to happen during the meantime.
Perhaps they were done by developers who were offline for some time,
perhaps they were actually different branches that now need to be
propagated back together - it doesn't really matter.

The key point is that you have a lot of merging work to do, that
you're trying to do it all in one revision, and that you don't
actually need to.  

You could go back up the two development lines finding revisions where
important changes were made, and merging those revisions together a
few changes at a time, progressively zippering together the
development lines with smaller merges until you catch up to the
present.  

This is essentially an effort in recreating the intermediate merging
nodes that didn't happen along the way. You also get the added benefit
of being able to carefully choose the revisions you merge to minimise
the overall work. DAG history is DAG history - it doesn't really
matter what calendar time each node in the graph was actually created,
and deferring merges in this way effectively allows you to avoid some
merges with the benefit of 'hindsight' you wouldn't have had at the
time - summarising a string of consecurtive nondisruptive changes on
one line into a single merge to the other, for example.

This is one of several reasons that I've encouraged developers not to
be scared of unmerged heads, even ones that persist for some time.

You get to work incrementally, saving (and, ideally, testing) your
work as you go. It might be convenient to use a temporary branch name
for this purpose if you like, of if you're happy just using explicit
revision id's, a local database and monotone-viz to pick nodes,
pushing all your work with the final merged head at the end.

Now, as with some of the other examples, the tools and UI support for
this style of work isn't entirely as nice as it could be.  I've done
this a couple of times, and I really do think it works very well and
uses the DAG hsitory to represent the real conceptual structure of
what happened well, but you do need to be pretty confident and
comfortable with using monotone and be prepared to do a little more
manual selection and explicit_merge'ing that would ideally be
desirable.   

I'm pretty sure I'd prefer this style of merging to a workspace merge
regardless: more properly, I think even when we have a workspace
merge, I'd probably *use* that merge interface in this progressive
incremental style, rather than rely on it to make big-bang merges
easier.

It even seems to me that there could be a reasonable amount of smarts
in the tool to support a zipper_merge workflow or commmand - for
example, when a conflict is detected, helping to find the nodes that
introduced the conflict higher up the tree, rather than trying to
merge the current heads that have inherited this conflict as well as
others.

--
Dan.

pgpsNlE3Fopte.pgp
Description: PGP signature