Paul Burba <ptburba_at_gmail.com> writes:
> 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?
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_at_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
Received on 2013-03-18 23:41:02 CET