subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Neyman <>
Subject Re: Show textual diff in a moved/copied file - how?
Date Tue, 27 Feb 2018 15:52:00 GMT
On 02/27/2018 03:26 AM, Johan Corveleyn wrote:
> On Tue, Feb 27, 2018 at 9:13 AM, Stefan Sperling <> 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 <> 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?


View raw message