Re: "svn diff -c" behavior on file copy from an old revision

On 2019-11-20 15:21:22 +0100, Johan Corveleyn wrote:
> Vincent Lefevre also wrote:
> >> 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
>
> Hm, it might be related, but I don't see this as exactly the same
> problem. IMHO this is normal and correct behavior.

I think that, as -c is documented, this is the same issue: "-c M" is a
shorthand for "-r N:M" with N = M−1. Thus

  svn diff -c3 file2

is equivalent to

  svn diff -r2:3 file2_at_BASE

Here, BASE is assumed to be 3 (or equivalent). Thus one should get the
difference between the contents corresponding to

  svn cat -r2 file2_at_3

and

  svn cat -r3 file2_at_3

> Indeed, in r2 there was no file2.

This is not really what is described here:

  http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html

OPERATIVE-REV is older than PEG-REV. Thus

1. Locate item in the revision identified by PEG-REV. There can be
   only one such object.

→ This is file2.

2. Trace the object's history backwards (through any possible renames)
   to its ancestor in the revision OPERATIVE-REV.

→ As I understand it, the history is as followed.

There is file2 at revision 3, which is a copy of file1 from revision 1.
At revision 1, this is file1. The renamed (and modification) occurred
at revision 3, thus I would say that revision 2 did not introduce a
change of the file, i.e. this is like file1_at_1. If the file is assumed
to be nonexistent, then this would mean that in the history line, it
has been removed, then re-added; this does not make sense to me, as
there was no such operation in the history.

> In r1 there was a predecessor of file2_at_3, namely file1_at_1. You could
> argue that in r2 it should show the contents of file1_at_1 (which were
> incidentally unchanged in r2).

Exactly, but the reason is not that file1 was unchanged in r2.
It is because that file1_at_1 is the latest ancestor or file2_at_3.

> But what if file1 would have been changed in r2 (yet file2_at_3 was a
> copy of file1_at_1), what would you expect svn to show?

Obviously file1_at_1, as file1_at_2 is *not* an ancestor of file2_at_3.
Just like file1_at_3 will not affect file2_at_3.

Remember, we are looking at the (backward) *history* of file2_at_3.

> Or what if file1 was deleted in r2?

Ditto, file1_at_1.

> I guess the same questions can be asked for 'svn diff -c 3' (what if
> file1 had a different content in r2, or was deleted in r2?). Yet in
> that case I intuitively expect "diff -c3" to take the copy-source into
> account, no matter if it has made a jump through history. As I argued
> in [3] above, it seems 'svnlook' can do this with its --diff-copy-from
> option ... (which I happen to like for generating diffs in post-commit
> emails).

My above interpretation of the history would have the advantage to
make it consistent with the current specification of "diff -c".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)