Paul Burba <ptbu...@gmail.com> writes: > 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?
Yes. >> 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. It's not just the mergeinfo that is difficult to understand. Your reverse merge example includes a text change: U contrib\client-side\svncopy\svncopy.pl.in my reverse merge does not include: U wc/f So the merge has not only elided the mergeinfo change, it has also removed the text change. Even if recording the reverse merge is impossible I'd still expect to see a text change. Using gdb I see that the merge: svn co file://`pwd`/repo/A wc svn merge -c-3 ^/A2 wc doesn't call svn_ra_do_diff3, in other words the whole merge has been elided. I guess it's related to this: svn co file://`pwd`/repo/A2@2 wc svn merge -c-3 ^/A2 wc svn: E195020: Cannot reverse-merge a range from a path's own future history; try updating first -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
