kot...@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 -->