On 17/12/2017 23:12, Evgeny Kotkov wrote:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
>> This language implies that we made a backwards incompatible change in 1.6,
>> which is not precisely the case; 1.6 simply started enforcing an API
>> requirement that 1.5 did not.
>> Could we perhaps rephrase this accordingly? I.e., point out that we weren't
>> inventing a backwards-incompatible requirement, but starting to enforce one
>> that had always been there?
> I would think that from the standpoint of a user reading the release notes,
> both versions look more or less the same (maybe, with the second one being
> slightly harder to parse due to its verbosity):
> Such property line endings were accepted by older servers and can be found
> in repository dumps, but are considered invalid starting with Subversion 1.6.
> Such invalid line endings were accepted by older servers and can be found
> in repository dumps of older repositories, but are rejected by Subversion 1.6
> and later.
> But, presumably, both variants are fine, as both of them explain the reason
> behind the "Cannot accept non-LF line endings" error — so please feel free
> to commit this tweak if you think it would be more appropriate.
> Evgeny Kotkov
When reading the initial text, I was wondering exactly the point
danielsh brought up. While to someone who is aware of the history, the
how and why of the invalid line endings in a dump file is fully clear
and he'd read both of the suggested descriptions absolutely the same (as
you did, Evgeny); someone who doesn't know/recall the details might in
fact wonder why the incompatibility behavior was introduced in 1.6 (as I
did). That's less likely to happen with danielsh's phrasing, since it
points out that these line endings were (always) considered invalid.
So to not just reply here without taking action, I went ahead and
committed danielsh's suggested change in r1818517.
Received on 2017-12-17 23:34:56 CET