On Tue, Feb 27, 2018 at 5:50 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Feb 27, 2018 at 07:52:00AM -0800, Alexey Neyman wrote:
>> Thanks for bringing up this explanation.
>
> Indeed!
> I had totally forgotten about this conversion from years ago.
>
>> 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?
>
> I wouldn't object to changing 'svn diff' to match the behaviour
> of 'svnlook diff' in this particular case. The inconsistency
> does not help anyone, and our compatibilty guarantees aren't
> *that* solid. We've certainly changed some output of our tooling
> when it helped our users, even where doing so hurt scripts.
+1. Backwards compatibility shouldn't block us from fixing bugs.
This certainly feels like a bug to me (the fact that it's inconsistent
depending on the operative revision range, and inconsistent with
'svnlook diff' where the behaviour seems more sane, is a strong
indication).
> I think my concerns were more about the effort involved, rather
> than compatibility. The process of adding --show-copies-as-adds
> was surprisingly difficult. I wouldn't want to go back to that
> code myself. I would review another brave soul's patches, though.
> The effort involved is easy to underestimate, unfortunately.
Putting Julian in cc because he was just talking about the diff code
on IRC today. You never know :-) ...
--
Johan
Received on 2018-02-27 23:08:15 CET