You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2017/12/17 19:15:17 UTC
Re: svn commit: r1818496 -
/subversion/site/staging/docs/release-notes/1.10.html
kotkov@apache.org wrote on Sun, 17 Dec 2017 17:19 +0000:
> +++ subversion/site/staging/docs/release-notes/1.10.html Sun Dec 17 17:19:23 2017
> @@ -692,6 +692,25 @@ or power loss, e.g. when loading a dump
> +<div class="h4" id="normalize-props">
> +<h4>New <tt>--normalize-props</tt> option for <tt>svnadmin load</tt>
> + <a class="sectionlink" href="#normalize-props"
> + title="Link to this section">¶</a>
> +</h4>
> +
> +<p>A new <tt>--normalize-props</tt> option has been added to the
> +<tt>svnadmin load</tt> command. This option can be used to automatically
> +repair <a href="/faq.html#fix-nonLF-log">non-LF line endings</a> in properties
> +such as <tt>svn:log</tt> or <tt>svn:ignore</tt>. 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.</p>
> +
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? Perhaps:
Such {+invalid+} line endings were accepted by older servers and can
be found in repository dumps {+of older repositories+}, but are
[-considered invalid starting with-]{+rejected by+} Subversion 1.6
{+and later+}.
Incidentally, this makes me wonder whether we shouldn't have just
allowed mixed line endings in svn:log, period. Of course I'm
fashionably late to raise this :-).
Cheers,
Daniel
> +<p>Calling <tt>svnadmin load</tt> with <tt>--normalize-props</tt> will
> +automatically repair all invalid property line endings found in the dumpstream,
> +thus ensuring that the appropriate values are loaded into the repository.</p>
> +
> +</div> <!-- normalize-props -->
Re: svn commit: r1818496 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan wrote on Sun, 17 Dec 2017 23:34 +0100:
> On 17/12/2017 23:12, Evgeny Kotkov wrote:
> > Daniel Shahaf <d....@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.
> >
> >
> > Thanks,
> > 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.
Thanks, Stefan. As you say, preventing an impression that we make
incompatible changes in minor releases was precisely my goal.
As to the new language being more verbose, I don't see how to
shorten it without losing details; the "of older repositories" phrase
does add useful information, IMO.
Cheers,
Daniel
Re: svn commit: r1818496 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan wrote on Sun, 17 Dec 2017 23:34 +0100:
> On 17/12/2017 23:12, Evgeny Kotkov wrote:
> > Daniel Shahaf <d....@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.
> >
> >
> > Thanks,
> > 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.
Thanks, Stefan. As you say, preventing an impression that we make
incompatible changes in minor releases was precisely my goal.
As to the new language being more verbose, I don't see how to
shorten it without losing details; the "of older repositories" phrase
does add useful information, IMO.
Cheers,
Daniel
Re: svn commit: r1818496 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Stefan <lu...@posteo.de>.
On 17/12/2017 23:12, Evgeny Kotkov wrote:
> Daniel Shahaf <d....@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.
>
>
> Thanks,
> 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.
Regards,
Stefan
Re: svn commit: r1818496 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Stefan <lu...@posteo.de>.
On 17/12/2017 23:12, Evgeny Kotkov wrote:
> Daniel Shahaf <d....@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.
>
>
> Thanks,
> 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.
Regards,
Stefan
Re: svn commit: r1818496 - /subversion/site/staging/docs/release-notes/1.10.html
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Daniel Shahaf <d....@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.
Thanks,
Evgeny Kotkov
Re: svn commit: r1818496 - /subversion/site/staging/docs/release-notes/1.10.html
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Daniel Shahaf <d....@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.
Thanks,
Evgeny Kotkov