subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Lefevre <>
Subject Re: "svn diff -c" behavior on file copy from an old revision
Date Thu, 21 Nov 2019 14:09:05 GMT
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@3" also shows a
> >> similar behavior:
> >>   -r1: one gets file1@1
> >>   -r2: "Unable to find repository location for..." error
> >>   -r3: one gets file2@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@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@3


  svn cat -r3 file2@3

> Indeed, in r2 there was no file2.

This is not really what is described here:

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@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@3, namely file1@1. You could
> argue that in r2 it should show the contents of file1@1 (which were
> incidentally unchanged in r2).

Exactly, but the reason is not that file1 was unchanged in r2.
It is because that file1@1 is the latest ancestor or file2@3.

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

Obviously file1@1, as file1@2 is *not* an ancestor of file2@3.
Just like file1@3 will not affect file2@3.

Remember, we are looking at the (backward) *history* of file2@3.

> Or what if file1 was deleted in r2?

Ditto, file1@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 <> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

View raw message