[cvsnt] Re: Branch merging - this seems wrong...

[Andreas Krey]

Gerhard Fiedler wrote:
...
> Branch A: that's where all other branches eventually end up. May be HEAD or
> anything else.
> Tag A1: developer B starts branch B.
> Tag A2: developer C starts branch C.
> Tag A3: developer C merges his changes from branch C back to A.
> Tag B1: dev. B needs the code from dev. C and merges it in from branch A.
> (repeat the cycle A2,A3,B1 ad lib)
> Tag A4: dev. B merges his code back to A.
> 
> A
> |
> A1----->B
> |       |
> A2-->C  |
> |    |  |
> A3<--+  |
> |       |
> +------>B1
> |       |
> A4<-----+
> |

...
> 4- Create the branches B and C and do the merge B1 as described. The
> advantage compared to 3 is that the final merge of B may be much easier.

This is because all the work is already done during the merges
from A to B. If there are multiple ones this means that the
individual conflict resolution happens earlier that in the
'we only merge to A' scenario, and memory is fresher. :-)

> Tony Hoyle called that "ouch messy" in another message :) and it may be,
> sometimes.

The 'ouch' only referred (as I understood it) to the need to manually
determine which three files should be the input to diff3 (which is at
the heart of every merge). And this is *exactly* the job of a version
control system.

...
> Most of my experience with extensive merges is with cvs servers (not cvsnt
> -- no merge points), so I cannot really comment much on how they work in
> any of these scenarios.

I have some second-hand experience with clearcase which has mergearrows.
Thus, as I heard that cvsnt has them too, I immediately voted to switch
from cvs to cvsnt. Then I learned the hard way that merge arrows aren't
everything, update -j also has to take them into account! Clearcase does
this (getting the right inputs for diff3) in a fabulous way that I don't
quite understand anymore.

...
> What might work is to use the change set of branch B /minus/ the change set
> from A1 to A4 -- that is, having a merge command option to tell cvsnt that
> all changes on A between the start of B and the tip of A should already be
> incorporated in B and that it should only consider the /other/ changes on
> B. (That would be a command for supporting specifically a scenario like
> option 4.) I'm not sure how realistic it would be to expect such an
> algorithm to work.

For this case it is almost trivial. Let's put some more modifications
in the branches:

  A
  |
  A1------>B0    # Set branch B on version A1 (B0 is the same as A1)
  |        |
  A2       |
  |        B1
  A3       |

A and B have been busy. Now we want to merge A into B, which
in the end yields a revision B2 (for example because A now has
something that B needs to complete his work).

  *------->B2    # Merge A up to A3 into B.

Obviously we need all changes from A1->A2->A3 and A1->(B0)->B1,
so the diff3 for merging must use A1 as base and A3 and B1
as the leafs.

Now we continue work.

  |        |
  A4       B3

and want to merge B back into A as our work there is completed.

Now, since the revisions A2 and A3 are already present in B,
we can not base the merge on revision A1. Instead we need to
look into the graph finding the closest common revision, which
is A3. We have change lines A3->B2-B3 and A3->A4, meaning that
we need to do diff3 with A3 as base and A4 and B3 als leaves.

Notice that the selection of versions to subject to diff3 is
actually independent of whether we are merging A->B or B->A.

Also notice that we could regard the first merge as changing
the branch structure so that B is now effectively rooted in
A3 instead of A1 for determining all further merge operations.
After a merge the 'merged-over' part of the graph becomes
irrelevant for that.

And finally this is just the same operation as if B were just
a sandbox. The merge A->B from A3 would be an normal update,
and the merge B<-A would be a commit (except that we always
need to merge into the sandbox first, granted).

Andreas

-- 
np: 4'33