On Thu, Nov 21, 2019 at 3:09 PM Vincent Lefevre <vincent-...@vinc17.net> wrote:
> 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
>
> and
>
> svn cat -r3 file2@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@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".
Ah, okay. Thanks for explaining. I can follow that.
So I agree this is probably the same issue, in that there is a similar
"bug in semantics".
If both commands ('svn cat -r2 file2@3' and 'svn diff -c3 file2', with
file2='svn copy file1@1') would use the IMHO very reasonable semantics
that you explain above, that would make sense to me.
As I said before in this thread, 'svnlook --diff-copy-from' seems to
be able to do it, so I think there is no purely technical reason why
it can't be done either.
--
Johan
