On Tue, Feb 27, 2018 at 9:13 AM, Stefan Sperling <s...@elego.de> wrote: > On Mon, Feb 26, 2018 at 04:52:41PM -0800, Alexey Neyman wrote: >> Why is the behavior different in these cases? Isn't that counter-intuitive >> as well that the diff's output depends on the source revision of the copy? > > I think these differences in behaviour boil down to side-effects of > the implementation.
As I posted before in this thread, this problem was already noted and discussed before on dev@ (feel free to follow the links I posted :-)). But I'm happy this issue is brought back to the foreground, because I too consider this an issue and inconsistent behaviour from the user's perspective (regardless of the underlying implementation problem). Back in 2013, you, Stefan, wrote: On Tue, Jun 25, 2013 at 10:56 PM, Stefan Sperling <s...@elego.de> wrote: > On Tue, Jun 25, 2013 at 10:26:08PM +0200, Ben Reser wrote: >> Back to your issue. Since Subversion can't represent the copy as part >> of the diff it tries to do the interoperable thing which is to >> represent the addition of a new file (from a copy) as an addition. > > That's not quite true in general. It's more like: > > 1) If the copyfrom source is part of the operative revision range of > the diff command, show a modification against the copyfrom source. > Unless --show-copies-as-adds was passed, because then we always > show copied files as an addition. > > 2) If the copyfrom source is not part of the operative revision range, > history of the file isn't traced back to that revision, so it appears > as an addition. > > It could be argued that 2) is weird special case, and that it should > behave like 1) (i.e. trace back to the copyfrom source anyway) and > only show an addition with --show-copies-as-adds. > > Johan pointed out that svnlook diff seems to traverse to the copyfrom > source even in case 2). If this is indeed the case, these commands are > now behaving in contradictory ways :( However, I think it's too late > to change either command now. -- Johan
