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

[Tony Hoyle]

Andreas Krey wrote:
  > 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.

In that case you'd lose the changes in B1....  you need that change as well, 
and since the other merges are potentially dependent on it you need to start 
there at a minimum.  The mergepoint doesn't help here.

You could optimise the case where there were no manual changes at all to the 
branch (in theory, don't know how easy that would be in practice, since you 
don't actually know that information at commit time.. perhaps some kind of 
diff with the source to determine exact equivalence) but the moment any change 
is made that is not the result of a simple merge then that's the earliest 
point you can take a merge from.

> 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.

If you're merging into A you always use the tip of A as the merge target. 
What matters is the source branch.  Mergepoints allow you do reduce complexity 
by ignoring parts of the source branch (since they have been already merged).

Tony