On Mon, Nov 18, 2019 at 4:44 AM Vincent Lefevre <vincent-...@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