On 02/27/2018 03:26 AM, Johan Corveleyn wrote:
> On Tue, Feb 27, 2018 at 9:13 AM, Stefan Sperling <stsp_at_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 <stsp_at_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.
Received on 2018-02-27 16:52:18 CET