You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pb...@collab.net> on 2007/02/28 23:39:43 UTC
[merge-tracking]: This looks ok, but is it?
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
RE: [merge-tracking]: This looks ok, but is it?
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: Daniel Rall [mailto:dlr@collab.net]
> Sent: Monday, March 05, 2007 7:34 PM
> To: dev@subversion.tigris.org
> Cc: Paul Burba
> Subject: Re: [merge-tracking]: This looks ok, but is it?
>
> On Wed, 28 Feb 2007, Paul Burba wrote:
...<snip>...
> > >svn merge
> >
> file:///C:/SVN.MERGE.TRACKING/src-trunk/Release/subversion/tests/cmdli
> > ne /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.
Note also that the svnmergeinfo property inheritence doesn't work even
when the nearest ancestor's mergeinfo is committed (Using standard greek
tree, cwd is root of WC):
>set
URL=file:///C:/SVN.MERGE.TRACKING/src-trunk/Release/subversion/tests/cmd
line/svn-test-work/repositories/merge_tests-1
>svn cp %URL%/A A_COPY
A A_COPY\B
A A_COPY\B\lambda
A A_COPY\B\E
A A_COPY\B\E\alpha
A A_COPY\B\E\beta
A A_COPY\B\F
A A_COPY\mu
A A_COPY\C
A A_COPY\D
A A_COPY\D\gamma
A A_COPY\D\G
A A_COPY\D\G\pi
A A_COPY\D\G\rho
A A_COPY\D\G\tau
A A_COPY\D\H
A A_COPY\D\H\chi
A A_COPY\D\H\omega
A A_COPY\D\H\psi
Checked out revision 1.
A A_COPY
>svn ci -m ""
Adding A_COPY
Committed revision 2.
>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo : /A:1
>echo new content > A\B\lambda
>svn ci -m ""
Sending A\B\lambda
Transmitting file data .
Committed revision 3.
>svn merge %URL%/A/B/lambda A_COPY\B\lambda
svn: A working copy merge source needs an explicit revision
>svn merge %URL%/A/B/lambda A_COPY\B\lambda -c3
U A_COPY\B\lambda
# 'A_COPY\B\lambda' should pick up r1 too.
>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo : /A:1
Properties on 'A_COPY\B\lambda':
svn:mergeinfo : /A/B/lambda:3
Paul B.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [merge-tracking]: This looks ok, but is it?
Posted by Daniel Rall <dl...@collab.net>.
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.