Re: Implicit keep-alive after reintegrate merge
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 31 Jan 2012 11:08:05 +0000 (GMT)
I agree that a symmetric merge algorithm would suffice for both 'sync' and 'reintegrate' merges.
I'm starting to write this up here: <http://wiki.apache.org/subversion/SvnMergeTheory>.
Subversion's current merge implementation makes assumptions in both the 'sync' and 'reintegrate' cases. (The part of the 'algorithm' I'm talking about is the part that looks at the mergeinfo and determines which three-way merge to perform next.) Specifically, I think the main assumptions are that 'sync' assumes the base for the 3-way merge is going to be on the source branch, while 'reintegrate' assumes the base is going to be on the target branch.
A slightly more general merge algorithm should be able to pick a base on either the source or the target branch depending on what was merged before, and so satisfy both of those cases. In order to do so, it needs to look more deeply at the mergeinfo that the courrent implementation does.
Branko Čibej wrote:
(I'm assuming that your b_at_r2 in this example is a simple copy with no diff,
But no, merge 3 should be even simpler than that. We don't have to go and fetch the old (b_at_r2:b_at_r4) and (b_at_r5:b_at_r6) diffs again and merge them into (a), because that's already been done recently and stored as (b_at_r8). So all we have to do is locate the youngest common ancestor of (b_at_r8) and (a_at_head), which is (a_at_r7), and do a single 3-way merge:
* merge 3: (mine=a_at_head, old=a_at_r7, yours=b_at_head)
(In this case this merge is trivial because mine==old, but if there had been a further change on (a), say in (a_at_r8), then it would be non-trivial.)
> Merge 3 is a cherry-pick merge, of course. But whatever you do, you
I don't follow all that about cherry-picking.
> The merge algorithm is symmetric.
That, I do agree with.
> SVN's mergeinfo has all the data that are
I know that Subversion stores sufficient info after a sync, and how to derive those merge arrows accurately from it; I'm about to check exactly what mergeinfo it stores after a reintegrate and make sure that's also sufficient.
Locating the youngest common ancestor is a step that needs further
This is an archived mail posted to the Subversion Dev mailing list.