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.
> When I did the 'reflective' merge itself, I got nothing as well:
>
> $ svn merge file:///Users/sussman/scratch/repos/branches/mybranch .
> --- Merging r19 into '.':
> U .
>
> $ svn diff
>
> Property changes on: .
> ___________________________________________________________________
> Added: svn:mergeinfo
> Merged /trunk:r16-18
> Merged /branches/mybranch:r19
>
>
> ...this makes no sense to me.
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.
--
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:16:03 2007