Re: Merging in CVS

[Kaz Kylheku]

"Paul D. Smith" <address@hidden> wrote in message news:<address@hidden>...
> This is good, and a long way better than base CVS, but it's still
> not really what ClearCase is capable of.
> 
> ClearCase creates an entirely new piece of metadata for every merge in
> each element recording the from/to versions.  That means that in
> ClearCase you can merge individual elements alone onto multiple
> branches, you don't have to merge the entire branch at once.
> 
> Also, ClearCase's merge algorithm actually takes into account the entire
> history of the element plus merge metadata, while Meta-CVS doesn't.
> This won't matter for simple merges where Meta-CVS provides the proper
> baseline, but it matters a great deal for complex merges which span
> multiple branches.  For example if you have a branch A, B, and C: you
> merge from A to C, then later you merge from A to B.  Then you want to
> merge from B to C--ClearCase will realize that for some elements it can
> use a more recent base version because of the previous merge of A to C.

Some time ago I spent a while racking my brains about problems like
this; and I came up with some solutions that will probably turn into
post 1.0 features, if anything.

One thing I can do in Meta-CVS is record the ancestry of a branch. So
that if you make branch A from the trunk, and then branch B from A, I
can record the fact that A is the ``parent'' of B, and the main trunk
is the parent of A.
Now this can help in merges if someone wants to go from B directly
down to the main trunk. We can perhaps see to what extent B has
already been merged to the intermediate A, and how much of A has
already gone down to the trunk.

At the very least, it's necessary to handle the branchpoint problem:
the first merge of B to the main trunk has to include all of the A
history from the A branchpoint to the B branchpoint; it can't just
start at the B branchpoint. Meta-CVS does not do this right; if you
merge from branch B, that means from the start of branch B. Is this
truly wrong? What if B is a feature that is independent of what
happened on branch A already? Hmm. The case can be made for having it
either way: merge only the B part, or merge the A ancestry as well.

It's clear that if you allow a lot of free branching in any direction
you end up with repeated merges. Version control systems which are
designed to support ``product branches'' from the start can
incorporate algorithms to deal with that.

In CVS we are kind of stuck with the model of ``merge back to your
immediate parent''.

> I'm not trying to put down Meta-CVS in any way: I think it's a great

Your criticism is perfectly rational and correct, which is all that
matters. Now if you want to see my response to some irrational
criticism, for your amusement, take a look at:
users.footprints.net/~kaz/mcvs-criticisms.html


:)