On Mon, Mar 18, 2013 at 3:26 PM, Philip Martin <philip.mar...@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
