On Tue, Feb 27, 2018 at 5:50 PM, Stefan Sperling <s...@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
