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

Re: Implicit keep-alive after reintegrate merge

From: Branko ─îibej <brane_at_apache.org>
Date: Tue, 31 Jan 2012 12:57:48 +0100

On 31.01.2012 12:08, Julian Foad wrote:
> (I'm assuming that your b_at_r2 in this example is a simple copy with no diff,
> otherwise the first part of 'merge 3' should use a_at_r1 instead of b_at_r2 for its base.)
> 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)
> diff3 a_at_r7 a_at_r7 b_at_r8 | patch a
> (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.)

Yeah, you're right, I forgot that b_at_r8 already has all the info. I got
muddled by my own example. :)
Since there are no cherry-picks in a->b merges, there would of course be
none in b->a merges, either.


> Locating the youngest common ancestor is a step that needs further
> explanation; it's not trivially obvious. We mean to follow the "merge
> arrows" that are shown on these graphs, as well as the basic lines of
> history. Each of these "merge arrows" means that all changes in the
> source branch have been merged into the target branch at that point. When modify this algorithm to cope with cherry-picking, that is
> to skip revisions that have already been cherry-picked, which we will need to do, then we will also have another kind of merge arrow on our graphs, a kind that doesn't mean all source changes have been merged to the target. The algorithm will get more complex. I won't talk about that here.)

Yes, it's complex. I'm almost sure that the current mergeinfo format can
represent cherry-picks correctly, though, so at least you won't have to
extend the format.

Cherry-picking is the part that really makes this hairy. But it might be
worth looking at the poor, defunct svnmerge.py, which /could/ properly
handle cherry-picks, at least most of the time. :)

Big cheer for grabbing this dragon by the horns, Julian.

-- Brane
Received on 2012-01-31 12:58:27 CET

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