I came across this while working on the elision tests and it got me
wondering a bit.
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
>
Am I right in thinking that there is no problem here?
Paul B.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 1 00:39:58 2007