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
We need a note on the "C" copy that it has two ancestors, A and B, not just
Then suppose just for confusion that new development sprouted all over:
To merge F and G, we find the common ancestor (B) and do three-way merge.
Now look at a really perverse case. When we come to merge H with G, there
Look at a typical case, where you repeatedly merge from HEAD, and finally
At the creation of 3 (the second merge from HEAD), it finds the common
So I don't see what the problem is in handling repeated merges; we just have
Am I missing some vital point?
Is svn already recording merge history in this manner?
--Nathanael
---------------------------------------------------------------------
|
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.