C. Michael Pilato wrote:
> Ben Collins-Sussman wrote:
>> I'm in the process of documenting basic merge tracking in the svnbook,
>> describing the basic process of managing a long-lived feature branch
>> and then merging it back to trunk. In the process, I've been
>> experimenting with (today's) trunk code, testing out the famed
>> 'reflective merge' scenario by hand.
>>
>> I'm using ra_local. I made a trunk, did some commits. Copied trunk
>> to branch. Then started making commits on both trunk and branch, back
>> and forth. As expected, 'svn merge trunkURL' in my branch-wc just did
>> the right thing. I did a bunch more commits to both trunk and branch,
>> and once again, 'svn merge trunkURL' did the right thing. (It's really
>> nice to have repeated branch synchronization so easy!)
>>
>> What's weird is when I tried to merge the branch back to trunk.
>> First, I made sure the branch was entirely synchronized with the
>> trunk. Then I went into my trunk-wc and tried to preview the merge:
>>
>> $ svn mergeinfo . --from-source
>> file:///Users/sussman/scratch/repos/branches/mybranch
>> Path: .
>>
>> $
>>
>> Wha? Nothing at all pending? No candidate ranges?
>
> This, uh, appears to be buggy. Sorry 'bout that.
By the way, I fixed this bug in r28347.
> What you're seeing is ... somewhat complex to explain. The merge logic
> today, in an attempt to help out with reflective merges, looks at the
> svn:mergeinfo diff that will be merged into your target -- like, the actual
> propdiff. In your case, it sees that across the range you are trying to
> merge (r16-19), the svn:mergeinfo on the branch directory changed. From
> what I see above, I'm guessing the change was the addition of
> "/trunk:r16-18". When it sees that diff, it says to itself, "Self, the
> range I'm trying to merge from the branch is basically the same stuff that
> was changed in /trunk:r16-18, and our target (trunk) already has changes
> from r16-18, so let's just skip this bit."
>
> Clearly, this behavior is horribly wrong, in two ways that I can quickly
> think of:
>
> 1. The logic doesn't check *which* of the revisions in your requested
> merge range resulted in the propdiff above. Had it done this,
> it would dropped only revision 19 from your merge back, and you
> would have gotten the right stuff.
>
> 2. The logic doesn't account for the fact that you might have, in r19,
> committed both the merge from trunk and a ton of other things, and
> is happy to skip both sets of changes.
>
> This is *exactly* the kind of stuff Kamesh (and many others) are thinking
> about and working on right now.
For those interested in the above, check out
libsvn_client/merge.c:filter_reflected_revisions() and its call stack.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 9 03:31:11 2007