[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Better repeated merge tracking...

From: Nathanael Nerode <neroden_at_twcny.rr.com>
Date: 2002-12-11 07:16:31 CET

I was thinking about graceful handling of repeated merges. Clearly the key
to this is tracking the history at the time of the early merges. For
instance, if we have a setup like
root->A->C
  |->B-----^

We need a note on the "C" copy that it has two ancestors, A and B, not just
one. If we view it as having A as the primary ancestor, then the "patch"
from A to C consists of the differences from the common ancestor (root) to B.
 If we view it as having B as the primary ancestor, then the "patch" from B
to C consists of the differences from root to A.

Then suppose just for confusion that new development sprouted all over:
root->D
A->E->H
B->F---^
C->G

To merge F and G, we find the common ancestor (B) and do three-way merge.
Similarly to merge E and G.

Now look at a really perverse case. When we come to merge H with G, there
are two common ancestor choices: A and B. If we pick A, then we have one
three-way merge (paths A->C->G and A->E->H), and if we pick B, then we have
a different three-way merge (B->C->G and B->F->H). This leads to a little
repetition, but not much, really.

Look at a typical case, where you repeatedly merge from HEAD, and finally
merge the whole branch in.
root->A->B->C->D->E
|->1---\>2-----\>3---/

At the creation of 3 (the second merge from HEAD), it finds the common
ancestor A and merges from there. At the final merger, for E, it finds the
common ancestor C and merges from there.

So I don't see what the problem is in handling repeated merges; we just have
to record multiple ancestors for the purposes of "merge" searching for a
common ancestor. (Not necessarily for other purposes.) Of course, a good
ancestor search algorithm might not be trivial, but you get the idea.

Am I missing some vital point?

Is svn already recording merge history in this manner?

--Nathanael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 11 14:12:42 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.