On Mon, Nov 18, 2019 at 4:44 AM Vincent Lefevre <vincent-svn_at_vinc17.net>
> 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_at_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
> 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_at_3" also shows a
> similar behavior:
> -r1: one gets file1_at_1
> -r2: "Unable to find repository location for..." error
> -r3: one gets file2_at_3
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
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?
Thanks again for writing.
Received on 2019-11-19 16:53:09 CET