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 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 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? -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
