Re: [merge-tracking]: This looks ok, but is it?

On Wed, 28 Feb 2007, Paul Burba wrote:
...
> Starting in the root directory of a vanilla greek tree:
>
> >svn info
> Path: .
> URL:
> file:///C:/SVN.MERGE.TRACKING/src-trunk/Release/subversion/tests/cmdline
> /svn-test-work/repositories/merge_tests-1
> <snip>
>
> # Make a simple branch and commit it
> >svn cp
> file:///C:/SVN.MERGE.TRACKING/src-trunk/Release/subversion/tests/cmdline
> /svn-test-work/repositories/merge_tests-1/A/B/E A/B/E_COPY
> A A\B\E_COPY\alpha
> A A\B\E_COPY\beta
> Checked out revision 1.
> A A\B\E_COPY
>
> >svn ci -m ""
> Adding A\B\E_COPY
>
> Committed revision 2.
>
> # Expected implied mergeinfo from copy
> >svn pl -vR
> Properties on 'A\B\E_COPY':
> svn:mergeinfo : /A/B/E:1
>
> # Make some changes in the source of the branch
> >echo "New content" > A\B\E\beta
>
> >svn ci -m ""
> Sending A\B\E\beta
> Transmitting file data .
> Committed revision 3.
>
> >echo "New content" > A\B\E\alpha
>
> >svn ci -m ""
> Sending A\B\E\alpha
> Transmitting file data .
> Committed revision 4.
>
> # Merge first change to source directly to
> # the affected file in the branch
> >svn merge
> file:///C:/SVN.MERGE.TRACKING/src-trunk/Release/subversion/tests/cmdline
> /svn-test-work/repositories/merge_tests-1/A/B/E/beta A\B\E_COPY\beta -c3
> U A\B\E_COPY\beta
>
> # Explicit mergeinfo added to beta
> >svn pl -vR
> Properties on 'A\B\E_COPY':
> svn:mergeinfo : /A/B/E:1
> Properties on 'A\B\E_COPY\beta':
> svn:mergeinfo : /A/B/E/beta:3
>
> # merge second change to source to parent directory
> # of the modified file...
> >svn merge
> file:///C:/SVN.MERGE.TRACKING/src-trunk/Release/subversion/tests/cmdline
> /svn-test-work/repositories/merge_tests-1/A/B/E A\B\E_COPY -c4
> U A\B\E_COPY\alpha
>
> # ...and A/B/E_COPY correctly picks up mergeinfo for r4, and
> # beta also picks up r4. This seems a bit odd as r4 doesn't
> # effect beta, but since the mergeinfo property "store(s) the
> # *full, complete* list of revisions that are directly merged
> # into the item." It's correct no? I wouldn't have thought
> # much about this but I noticed that if the merges are performed
> # in reverse order from above, the results are not the same...
> >svn pl -vR
> Properties on 'A\B\E_COPY':
> svn:mergeinfo : /A/B/E:1,4
> Properties on 'A\B\E_COPY\beta':
> svn:mergeinfo : /A/B/E/beta:3-4
>
> # ...revert the merges and then apply them in reverse order.
> >svn revert -R .
> Reverted 'A\B\E_COPY'
> Reverted 'A\B\E_COPY\alpha'
> Reverted 'A\B\E_COPY\beta'
>
> svn pl -vR
> Properties on 'A\B\E_COPY':
> svn:mergeinfo : /A/B/E:1
>
> >svn merge
> file:///C:/SVN.MERGE.TRACKING/src-trunk/Release/subversion/tests/cmdline
> /svn-test-work/repositories/merge_tests-1/A/B/E A\B\E_COPY -c4
> U A\B\E_COPY\alpha
>
> >svn pl -vR
> Properties on 'A\B\E_COPY':
> svn:mergeinfo : /A/B/E:1,4
>
> >svn merge
> file:///C:/SVN.MERGE.TRACKING/src-trunk/Release/subversion/tests/cmdline
> /svn-test-work/repositories/merge_tests-1/A/B/E/beta A\B\E_COPY\beta -c3
> U A\B\E_COPY\beta
>
> # A\B\E_COPY\beta doesn't have r4, but again r4 doesn't
> # affect beta, so it is semantically equivalent to
> # /A/B/E/beta:3-4
> >svn pl -vR
> Properties on 'A\B\E_COPY':
> svn:mergeinfo : /A/B/E:1,4
> Properties on 'A\B\E_COPY\beta':
> svn:mergeinfo : /A/B/E/beta:3
...

Paul and I discussed this last week in person at CollabNet's Brisbane
office, and came to the conclusion that path 'A\B\E_COPY\beta' should
have the merge info '/A/B/E/beta:1,3-4'.

Because path 'A\B\E_COPY\beta' has no explicit merge info, revisions 1
and 4 are inherited from local (uncommitted) merge info on parent path
'A\B\E_COPY'. The client library should be walking back up the WC
until it encounters either a) the WC root or b) local merge info. If
it encounters (b), it should use a copy of that merge info as the
basis for the merge info of the target of the merge.