Update 1.10 release notes

Gbp-Dch: Ignore
Signed-off-by: James McCoy <jamessan@debian.org>

1 files changed, 168 insertions, 11 deletions

diff --git a/debian/svn_1.10_releasenotes.html b/debian/svn_1.10_releasenotes.html
index 3e400a8..c30107a 100644
--- a/debian/svn_1.10_releasenotes.html
+++ b/debian/svn_1.10_releasenotes.html
@@ -120,7 +120,9 @@
 
 <div class="notice">
 <p><span style="color: red"><b>This is work in progress.
-  Subversion 1.10 has not been released yet.</b></span></p>
+  Subversion 1.10 has not been released yet.<br>
+  2018-03-23 status: Blocker bugs found in RC1; RC2 coming soon (<a href="/roadmap.html">Roadmap</a>, <a href="https://issues.apache.org/jira/browse/SVN-4712">issue SVN-4712</a>)
+  </b></span></p>
 </div>
 
 <div class="h2" id="news">
@@ -231,7 +233,7 @@ and what impact these changes may have.</p>
     <td>Use SVN 1.8 and above clients only for best results.</td></tr>
   <tr>
     <td>
-      <a href="#lz4">LZ4 compression over the wire in http:// connections</a>
+      <a href="#lz4-over-the-wire">LZ4 compression over the wire in http:// and svn:// connections</a>
     </td>
     <td>1.10</td>
     <td>1.10</td>
@@ -637,7 +639,9 @@ containing large files.
 </p>
 
 <p>LZ4 compression is now used by default for the on-disk data in repositories
-with filesystem format 8 (see below).</p>
+with filesystem format 8.  Also, Subversion 1.10 adds support for automatic
+negotiation and use of LZ4 compression over the wire for http:// and svn://
+connections when it is supported by both endpoints.</p>
 
 <p><b>Note:</b> this does not apply to the pre-release
 <a href="https://lists.apache.org/thread.html/dd78432b301f3f95567930c242c46b308c8a017fd754c0f388245915@%3Cannounce.subversion.apache.org%3E">Subversion 1.10.0-alpha3</a>
@@ -649,9 +653,12 @@ version, which still uses zlib compression by default.
      title="Link to this section">&para;</a>
 </h4>
 
-<p>The default filesystem format is now a new format, numbered 8.  The format
+<p>The default filesystem format is now version 8, introduced in 1.10.
+The format
 bump is required to allow using LZ4 compression for the data that is stored
-on the disk.  (The <tt>svnadmin info</tt> command displays the filesystem
+on the disk.  (The
+<a href="1.9#svnadmin-info"><tt>svnadmin info</tt></a>
+command displays the filesystem
 format number of a repository.)</p>
 
 <p>Existing repositories can be upgraded to the new format with the
@@ -670,7 +677,7 @@ format number of a repository.)</p>
 
 <div class="h4" id="fsfs-lz4-configuration">
 <h4>Configuring the repository to use LZ4 compression
-  <a class="sectionlink" href="#fsfs-format8"
+  <a class="sectionlink" href="#fsfs-lz4-configuration"
      title="Link to this section">&para;</a>
 </h4>
 
@@ -694,6 +701,119 @@ cycle into a new format 8 repository created with Subversion 1.10.
 
 </div>  <!-- fsfs-lz4-configuration -->
 
+<div class="h4" id="lz4-over-the-wire">
+<h4>LZ4 compression over the wire in http:// and svn:// connections
+  <a class="sectionlink" href="#lz4-over-the-wire"
+     title="Link to this section">&para;</a>
+</h4>
+
+<p>Deltas transferred between Subversion 1.10 clients and servers may be
+compressed with LZ4.  The actual choice of the compression algorithm depends
+on the used protocol, environment and its configuration &mdash; see below.</p>
+
+<p>For <b>http://</b> protocol, use of LZ4 compression depends on the values
+of the server-side <tt>SVNCompressionLevel</tt> directive, client-side
+<tt>http-compression</tt> configuration option and on the network
+capabilities.  LZ4 compression generally offers much faster compression
+and decompression speeds, but slightly worse compression ratio than zlib.
+By default, it is only preferred for low latency networks where the
+overhead associated with transferring the additional amount of data is
+assumed to be negligible.<p>
+
+<ul>
+  <li>
+    <p>On the <b>server-side</b>, <tt>SVNCompressionLevel 0</tt>
+    can be used to disable compression altogether.  The special value of
+    <tt>SVNCompressionLevel 1</tt> forces the use of LZ4 compression for
+    clients that support it. All other values result in preferring zlib
+    compression with the respective compression level.  Note that the
+    negotiated algorithm is still subject to the client's configuration.
+    For example, even if the server is configured to prefer zlib compression
+    over LZ4, a client may still negotiate the use of LZ4 compression when
+    its <tt>http-compression</tt> option is set to <tt>auto</tt>.</p>
+  </li>
+  <li>
+    <p>On the <b>client-side</b>, setting <tt>http-compression</tt> to
+    either <tt>yes</tt> or <tt>no</tt> will enable or disable compression
+    that is then negotiated based on the server's configuration.
+    The default value of <tt>auto</tt> will result in preferring LZ4
+    compression for low latency networks and zlib compression otherwise.</p>
+  </li>
+</ul>
+
+<p>Below is the table explaining the used compression algorithm in each
+combination of the client- and server-side configuration options:</p>
+
+<table border="1">
+  <tr>
+    <th></th>
+    <th colspan="3">1.10 Server<br />with SVNCompressionLevel:</th>
+    <th colspan="2">1.9 and older Server<br />with SVNCompressionLevel:</th>
+  </tr>
+  <tr>
+    <th>Subversion Client</th>
+    <th>0</th>
+    <th>1</th>
+    <th>2-9 (default:&nbsp;5)<sup>*</sup></th>
+    <th>0</th>
+    <th>1-9 (default:&nbsp;5)<sup>*</sup></th>
+  </tr>
+  <tr>
+    <td>1.10, <tt>http-compression: auto</tt><sup>*</sup>, low latency</td>
+    <td>No compression</td>
+    <td><b>LZ4</b> compression</td>
+    <td><b>LZ4</b> compression</td>
+    <td>No compression</td>
+    <td>zlib compression</td>
+  </tr>
+  <tr>
+    <td>1.10, <tt>http-compression: auto</tt><sup>*</sup>, high latency</td>
+    <td>No compression</td>
+    <td><b>LZ4</b> compression</td>
+    <td>zlib compression</td>
+    <td>No compression</td>
+    <td>zlib compression</td>
+  </tr>
+  <tr>
+    <td>1.10, <tt>http-compression: yes</tt></td>
+    <td>No compression</td>
+    <td><b>LZ4</b> compression</td>
+    <td>zlib compression</td>
+    <td>No compression</td>
+    <td>zlib compression</td>
+  </tr>
+  <tr>
+    <td>1.10, <tt>http-compression: no</tt></td>
+    <td>No compression</td>
+    <td>No compression</td>
+    <td>No compression</td>
+    <td>No compression</td>
+    <td>No compression</td>
+  </tr>
+  <tr>
+    <td>1.9 and older, <tt>http-compression: yes</tt><sup>*</sup></td>
+    <td>No compression</td>
+    <td>zlib compression</td>
+    <td>zlib compression</td>
+    <td>No compression</td>
+    <td>zlib compression</td>
+  </tr>
+  <tr>
+    <td>1.9 and older, <tt>http-compression: no</tt></td>
+    <td>No compression</td>
+    <td>No compression</td>
+    <td>No compression</td>
+    <td>No compression</td>
+    <td>No compression</td>
+  </tr>
+</table>
+
+<p><sup>*</sup>&nbsp;Default configurations</p>
+
+<!-- TODO: describe LZ4 over svn:// -->
+
+</div>  <!-- lz4-over-the-wire -->
+
 </div>  <!-- lz4 -->
 
 <div class="h3" id="shelving">
@@ -780,7 +900,7 @@ as a single, efficient server-side query.
 
 <p><tt>svnbench</tt> now displays its wall-clock run time and the total
 number of bytes transferred across the network. The <tt>--with-no-revprops</tt>
-option which did not actually work in Subversion 1.9 haas been fixed.</p>
+option which did not actually work in Subversion 1.9 has been fixed.</p>
 
 </div> <!-- svnbench -->
 
@@ -809,6 +929,21 @@ by default instead.
      title="Link to this section">&para;</a>
 </h3>
 
+<div class="h4" id="revprop-caching">
+<h4>Revprop caching enabled</tt>
+  <a class="sectionlink" href="#revprop-caching"
+     title="Link to this section">&para;</a>
+</h4>
+
+<p>Revprop caching was an optional FSFS feature in previous releases
+but is now always enabled.  In previous releases revprop caching could
+be enabled for mod_dav_svn via the <tt>SVNCacheRevprops</tt>
+directive, and for svnserve by the <tt>--cache-revprops</tt> command
+line option.  That directive and command line option are now silently
+ignored and revprop caching is enabled for all FSFS access.</p>
+
+</div> <!-- revprop-caching -->
+
 <div class="h4" id="no-flush-to-disk">
 <h4>New <tt>--no-flush-to-disk</tt> option for <tt>svnadmin load</tt>
   <a class="sectionlink" href="#no-flush-to-disk"
@@ -861,6 +996,7 @@ revision properties in a repository to the values saved in a dump file.</p>
 
 <div class="h4" id="dump-include-exclude">
 <h4><tt>svnadmin dump</tt> can now include or exclude paths
+  (<a href="https://issues.apache.org/jira/browse/SVN-4729">issue #4729</a>)
   <a class="sectionlink" href="#dump-include-exclude"
      title="Link to this section">&para;</a>
 </h4>
@@ -939,17 +1075,38 @@ if they occur.</p>
 
 </div>  <!-- troubleshooting -->
 
+<div class="h2" id="svn-1.9-old-stable">
+<h2>Subversion 1.9.x is now the old stable version
+  <a class="sectionlink" href="#svn-1.9-old-stable"
+    title="Link to this section">&para;</a>
+</h2>
+
+<p>The Subversion 1.9.x line is now the old stable version.  This means
+that 1.9.x will still receive security relevant fixes as well as
+bugfixes. While we will evaluate any bugreport with regards to its
+severity, there might be issues with a lower severity which will
+only get fixed in 1.10.x, particularly if the patches would be invasive,
+destabilizing, and/or require a significant investment to get backported to the
+old stable version.</p>
+
+<p>Therefore, if you are running into an issue with the old stable
+version which has already been fixed in the latest version, we might
+ask you to upgrade to that version to resolve the issue.</p>
+
+</div>  <!-- svn-1.9-old-stable -->
+
 <div class="h2" id="svn-1.8-deprecation">
-<h2>Subversion 1.8.x series no longer supported
+<h2>Subversion 1.8.x is end of life
   <a class="sectionlink" href="#svn-1.8-deprecation"
     title="Link to this section">&para;</a>
 </h2>
 
-<p>The Subversion 1.8.x line is no longer supported.  This doesn't
+<p>The Subversion 1.8.x line is end of life (<abbr title="End Of Life">EOL</abbr>).
+This doesn't
 mean that your 1.8 installation is doomed; if it works well and is all
-you need, that's fine.  "No longer supported" just means we've stopped
+you need, that's fine.  "End of life" just means we've stopped
 accepting bug reports against 1.8.x versions, and will not make any
-more 1.8.x bugfix releases.</p>
+more 1.8.x releases.</p>
 
 </div>  <!-- svn-1.8-deprecation -->