Inconsistent merge on subdirectory behavior?

[Chris]

I wanted to reverse-merge some accidental changes on a subdirectory on my branch and svn really confuses me in this. Is the below behavior from subversion intended or have I stubled on a bug?

I wanted to reverse-merge revision 1000 on all the files in the directory "sub/dir", below illustrated with only one file.

wcroot> svn diff --summarize -c 1000 sub/dir
M sub/dir/foobar.txt
wcroot> svn merge -c -1000 sub/dir
--- Recording mergeinfo for reverse merge of r1000 into '.':
U .
So the file sub/dir/foobar.txt is not reverse-merged (and the merge info is elided even though the output does not say so)

I tried a few different versions of this with e.g. -r 1000:999 with identical results.

Then I did the following, which I thought would be more of the same:

wcroot> cd foo/bar
wcroot/foo/bar> svn merge -c -1000 .
--- Reverse-merging r1000 into '.':
U sub/dir/foobar.txt
--- Recording mergeinfo for reverse merge of r1000 into '.':
G .
--- Eliding mergeinfo from '.':
U .

So now it does what I wanted to.

Is it intended that merge should do different things if I use "." or "sub/dir" as my WCTARGET? I find it confusing and it was mostly luck that I stumbled on the right solution. "svn help merge" does not seem to indicate that these two use cases should be any different, but I may misread it.
Btw, this was done with "svn, version 1.9.5 (r1770682)"

TIA,
Chris

[Johan Corveleyn]

Post by Chris
I wanted to reverse-merge some accidental changes on a subdirectory on my branch and svn really confuses me in this. Is the below behavior from subversion intended or have I stubled on a bug?
I wanted to reverse-merge revision 1000 on all the files in the directory "sub/dir", below illustrated with only one file.
wcroot> svn diff --summarize -c 1000 sub/dir
M sub/dir/foobar.txt
wcroot> svn merge -c -1000 sub/dir
U .
So the file sub/dir/foobar.txt is not reverse-merged (and the merge info is elided even though the output does not say so)
I tried a few different versions of this with e.g. -r 1000:999 with identical results.
wcroot> cd foo/bar
wcroot/foo/bar> svn merge -c -1000 .
U sub/dir/foobar.txt
G .
U .
So now it does what I wanted to.
Is it intended that merge should do different things if I use "." or "sub/dir" as my WCTARGET? I find it confusing and it was mostly luck that I stumbled on the right solution. "svn help merge" does not seem to indicate that these two use cases should be any different, but I may misread it.
Btw, this was done with "svn, version 1.9.5 (r1770682)"
TIA,
Chris

Hi Chris,

That does seem strange. However it's quite hard to diagnose this from
your description alone, because there are a lot of things that can
play a role in the merge algorithm.

Would you be able to come up with a reproduction script, or even just
a transcript of you reproducing the issue, starting from a clean
repository ('svnadmin create'; ...)?

For a reproduction script you could use the repro-template.sh or
repro-template.bat linked from here:
https://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs

Thanks,

[Chris]

Hi Johan and thanks for the reply.

I made a very simple reproduction script and attached it to this mail, the behavior seems to be easy to reproduce. Haven't made a reproducton script before so I'm not sure how you want the issue to be explained, but I first did the behavior that I think is incorrect and did a status+echo and then the same from a subdirectory with a second status+echo.

If you instead wanted me to make a bug report on the tracker, let me know.

/Chris


--------------------------------------------
On Fri, 4/13/18, Johan Corveleyn <***@gmail.com> wrote:

Subject: Re: Inconsistent merge on subdirectory behavior?
To: "Chris" <***@yahoo.se>
Cc: "Subversion" <***@subversion.apache.org>
Date: Friday, April 13, 2018, 2:49 PM

On Wed, Apr 11, 2018 at 4:56 PM,

Post by Chris
I wanted to reverse-merge some accidental

changes on a subdirectory on my branch and svn really
confuses me in this. Is the below behavior from subversion
intended or have I stubled on a bug?

Post by Chris
I wanted to reverse-merge revision 1000 on

all the files in the directory "sub/dir", below
illustrated with only one file.

Post by Chris
wcroot> svn diff --summarize -c 1000

sub/dir

Post by Chris
M sub/dir/foobar.txt
wcroot> svn merge -c -1000 sub/dir
--- Recording mergeinfo for reverse merge
  U  .
So the file sub/dir/foobar.txt is not

reverse-merged (and the merge info is elided even though the
output does not say so)

Post by Chris
I tried a few different versions of this

with e.g. -r 1000:999 with identical results.

Post by Chris
Then I did the
wcroot> cd

foo/bar

Post by Chris
wcroot/foo/bar> svn merge -c

-1000 .

Post by Chris
--- Reverse-merging r1000 into
U   

sub/dir/foobar.txt

Post by Chris
--- Recording
  G  .
--- Eliding
  U  .
So now it does what I

wanted to.

Post by Chris
Is it

intended that merge should do different things if I use
"." or "sub/dir" as my WCTARGET? I find
it confusing and it was mostly luck that I stumbled on the
right solution. "svn help merge" does not seem to
indicate that these two use cases should be any different,
but I may misread it.

Post by Chris
Btw, this was

done with "svn, version 1.9.5 (r1770682)"

Post by Chris
TIA,
  Chris

Hi Chris,

That
does seem strange. However it's quite hard to diagnose
this from
your description alone, because
there are a lot of things that can
play a
role in the merge algorithm.

Would you be able to come up with a
reproduction script, or even just
a
transcript of you reproducing the issue, starting from a
clean
repository ('svnadmin create';
...)?

For a reproduction
script you could use the repro-template.sh or
repro-template.bat linked from here:
https://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs

Thanks,
--
Johan

[Stefan Sperling]

Post by Chris
Hi Johan and thanks for the reply.
I made a very simple reproduction script and attached it to this mail, the behavior seems to be easy to reproduce. Haven't made a reproducton script before so I'm not sure how you want the issue to be explained, but I first did the behavior that I think is incorrect and did a status+echo and then the same from a subdirectory with a second status+echo.
If you instead wanted me to make a bug report on the tracker, let me know.
/Chris

Thank you very much for writing and providing this script.

I agree that this problem looks like a bug. If you have time to
do so, please file an issue in our issue tracker.

The problem also affects 'svn diff'.
A reasonable expectation would be that the reverse of a diff which
adds something is a diff which deletes something, but in this case
the reverse diff produced by SVN is an empty diff:

$ svn diff -c2 ^/trunk/A
Index: foo
===================================================================
$ svn diff -c2 A
Index: A/foo
===================================================================
$ svn diff -c-2 A
$ svn diff -c2 ^/trunk/A
Index: foo
===================================================================
$ svn diff -c-2 ^/trunk/A
$

[Chris]

Hi,

I created an issue in Jira: https://issues.apache.org/jira/browse/SVN-4737 and added a reference back to this thread in that one.
I'm wasn't sure how to set some of the fields, but hopefully sufficient to track down the issue in the future.

/Chris


--------------------------------------------
On Sun, 4/15/18, Stefan Sperling <***@apache.org> wrote:

Subject: Re: Inconsistent merge on subdirectory behavior?
To: "Chris" <***@yahoo.se>
Cc: "Johan Corveleyn" <***@gmail.com>, "Subversion" <***@subversion.apache.org>
Date: Sunday, April 15, 2018, 4:10 PM

On Sun, Apr 15, 2018 at 12:49:49PM +0000, Chris

Post by Chris
Hi Johan and thanks for the reply.
I made a very simple

reproduction script and attached it to this mail, the
behavior seems to be easy to reproduce. Haven't made a
reproducton script before so I'm not sure how you want
the issue to be explained, but I first did the behavior that
I think is incorrect and did a status+echo and then the same
from a subdirectory with a second status+echo.

Post by Chris
If you instead

wanted me to make a bug report on the tracker, let me
know.
/Chris

Thank you very
much for writing and providing this script.

I agree that this problem
looks like a bug. If you have time to
do so,
please file an issue in our issue tracker.

The problem also affects
'svn diff'.
A reasonable expectation
would be that the reverse of a diff which
adds something is a diff which deletes
something, but in this case
the reverse diff
produced by SVN is an empty diff:

$ svn diff -c2 ^/trunk/A 
Index: foo
===================================================================
$ svn diff -c2 A         
Index: A/foo
===================================================================
$ svn diff -c-2 A
$ svn diff
-c2 ^/trunk/A 
Index: foo
===================================================================
$ svn diff -c-2 ^/trunk/A
$


-----Inline Attachment Follows-----