To clarify my merge-tracking proposal more in detail:
It seems to me that the important aspect is that mergeinfo
should contain only entries from *direct* merges.
In this way, the mergeinfo build a tree.
(This merge history tree information is missing in the
current mergeinfo scheme, which contains both direct
*and* indirect merges.)
def smart_merge(source, -r X:Y, target):
def is_1_contained_in_tree_2(path1@r1, path2@r2):
if path1@r1 == path2@r2:
return True
for each subpath@subr which is in mergeinfo of path2@r2,
but not in mergeinfo of path2@(r2-1):
if is_1_contained_in_tree_2(path1@r1, subpath@subr):
return True
return False
def undo_existing_changes_1_in_2(path1@r1, path2@r2):
if is_1_contained_in_tree_2(path1@r1, path2@r2):
merge path1 -r r1:(r1-1) from target
else:
for each subpath@subr which is in mergeinfo of path1@r1,
but not in mergeinfo of path1@(r1-1)
in reverse(!) revision order:
undo_existing_changes_1_in_2(subpath@subr, path2@r2)
for i2 = LATEST_REV downto 1:
for i1 = Y downto X+1:
if mergeinfo of target does not contain source@i1:
undo_existing_changes_1_in_2(source@i1, target@i2)
for i1 = X+1 to Y:
if mergeinfo of target does not contain source@i1:
merge source -r i1-1:i1 into target
add source@i1 to mergeinfo of target.
This should handle both
http://svn.haxx.se/dev/archive-2007-12/0134.shtml
and
http://svn.haxx.se/dev/archive-2007-11/1265.shtml
correctly.
This is a brute-force implementation, which of course could be optmized
to work on revision ranges instead of individual revisions.
But this is "only" an implementation detail.
The above pseudo-code is just quickly written down
and may be buggy, but I think you get the idea.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 4 22:55:02 2007