On 31.01.2012 12:08, Julian Foad wrote:
> (I'm assuming that your b@r2 in this example is a simple copy with no diff,
>  otherwise the first part of 'merge 3' should use a@r1 instead of b@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@r2:b@r4) and (b@r5:b@r6) diffs again and merge them into 
> (a), because that's already been done recently and stored as (b@r8).  So all 
> we have to do is locate the youngest common ancestor of (b@r8) and (a@head), 
> which is (a@r7), and do a single 3-way merge:
>
>   * merge 3: (mine=a@head, old=a@r7, yours=b@head)
>     diff3 a@r7 a@r7 b@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@r8), then it would be non-trivial.)

Yeah, you're right, I forgot that b@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

Reply via email to