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". -- Vincent Lefèvre <vinc...@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)
