On Mon, Nov 18, 2019 at 4:44 AM Vincent Lefevre <vincent-svn@vinc17.net> wrote:
I have the following issue with svn 1.10.6:

Assume that I committed "file1" at revision 1, did some unrelated
change at revision 2, and for revision 3, copied "file1@1" to "file2"
with "svn copy"[*] and did some changes in file2 before the commit.

[*] The revision older than the latest one is what happens when one
does a "svn copy" directly from the working copy without an update
first.

If I do "svn diff -r 1:3 file2", then I get the changes that have been
introduced between file1 and file2. But if I do "svn diff -c 3 file2",
which is equivalent to "svn diff -r 2:3 file2", then I get the whole
file2 content, as if file2 were an entirely new file.

I'm wondering whether this is the expected behavior. In any case,
this behavior is rather unintuitive and rather useless. I think there
should be an easy way to get the changes introduced by a commit.

Note: "svn cat -r... file2" or "svn cat -r... file2@3" also shows a
similar behavior:
  -r1: one gets file1@1
  -r2: "Unable to find repository location for..." error
  -r3: one gets file2@3

Hello Vincent,

Thank you for reporting this.

I think it is the expected behavior because file2 does not exist in revision 2 and by using '-c 3' (equivalent to -r 2:3) you're restricting the revisions that are included in the differencing; as it does not follow the copy source farther back than revision 2, the file is considered a new file.

In contrast, with -r 1:3, since the revisions are not restricted (or at least not as restricted; revision 1 is now included in the differencing), it follows the copy backwards to revision 1 and shows only the differences.

I agree it would be nice if it could show only the changes in the copy, but then a command like 'diff -r 2:3' would be ambiguous... How would it know if you want it to trace history beyond the range specified, or if you want it to respect the -r 2:3 limit?

Thoughts?

Thanks again for writing.

Nathan