On 02/27/2018 03:26 AM, Johan Corveleyn wrote:
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.
Thanks for bringing up this explanation. So the second inconsistency is
because '-c X' actually defines operative range X-1:X and the source of
the copy is X-2 in this case.
Indeed, a lot of subtleties and inconsistencies that appear to be bugs.
Is there ever going to be SVN 2.0 that can finally break these
bug-for-bug compatibility promises? Is there a list of things that are
going to be changed in 2.0?
Regards,
Alexey.
