On Mon, Mar 18, 2013 at 3:26 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> This is one of the issues blocking 1.8. I don't really understand the
> merge behaviour. Consider this test case: a file in a directory,
> branch, modify the file on the branch:
>
> svnadmin create repo
> svn -mm import repo/format file://`pwd`/repo/A/B/f
> svn -mm cp file://`pwd`/repo/A ^/A2
> svnmucc -mm put repo/README.txt file://`pwd`/repo/A2/B/f
>
> Now merge the change back to the original branch:
>
> svn co file://`pwd`/repo/A wc
> svn merge -c3 ^/A2 wc
>
> that works and modifies wc/B/f and records the merge. Then reverse merge
>
> svn merge -c-3 ^/A2 wc
>
> and the change is undo leaving a pristine working copy. That all
> seems fine.
>
> However a reverse merge alone does nothing (call this case A):
>
> svn co file://`pwd`/repo/A wc
> svn merge -c3 ^/A2 wc
You mean 'svn merge -c-3 ^/A2 wc' right?
> The notifications say:
>
> --- Recording mergeinfo for reverse merge of r3 into 'wc':
> U wc
> --- Eliding mergeinfo from 'wc':
> U wc
>
> and overall there are no changes in the working copy. I don't really
> understand that
The notifications could be handled better in these cases. Right now
the merge code assumes that a mergetracking aware merge will record
mergeinfo describing the merge and that that mergeinfo will mean
something. For forward merges this is always the case, but not so for
reverse merges. This is the same thing we see when reverting a change
using a reverse merge from the same branch's history:
# Starting with an unmodified WC for ^/subversion/trunk, say we want to
# revert a recent commit:
C:\SVN\src-trunk-4>svn merge ^^/subversion/trunk -c-1457920
--- Reverse-merging r1457920 into '.':
U contrib\client-side\svncopy\svncopy.pl.in
--- Recording mergeinfo for reverse merge of r1457920 into '.':
U .
# We claim to have recorded mergeinfo describing the merge, and we
did, it's just that it's
# identical to what we started with (since we don't currently have a
way of representing
# reverse merges in svn:mergeinfo -
http://subversion.tigris.org/issues/show_bug.cgi?id=2881)
C:\SVN\src-trunk-4>svn st
M contrib\client-side\svncopy\svncopy.pl.in
The situation is a bit odder in your example because there is no
pre-existing mergeinfo on the merge target, so the mergeinfo
describing the merge is simply "" and that elides away.
> but it's not new behaviour, 1.7 was the same.
>
> Next consider merging the wrong URL:
>
> svn co file://`pwd`/repo/A wc
> svn merge -c3 ^/A2/B wc
>
> that gives a tree-conflict on wc/f. The cherry-pick merge doesn't check
> ancestyr, gets a diff from the repository, and fails to apply it because
> the paths don't match. That seems OK.
>
> Now try the reverse merge alone (call this case B):
>
> svn co file://`pwd`/repo/A wc
> svn merge -c-3 ^/A2/B wc
>
> Again the notifications say:
>
> --- Recording mergeinfo for reverse merge of r3 into 'wc':
> U wc
> --- Eliding mergeinfo from 'wc':
> U wc
>
> and overall there are no changes in the working copy. If this merge
> attempted to merge the change the tree-conflict would indicate to the
> user that the wrong URL was used.
>
> I'm not sure why cases A and B don't attempt to merge changes. Can
> anyone explain the behaviour?
Wow, that is surprising. I can't explain it either...1.7 behaves the same...
...investigating
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Received on 2013-03-18 21:56:07 CET