svn commit: r1693909 - /subversion/site/publish/docs/release-notes/1.9.html

[st...@apache.org]

Author: stefan2
Date: Mon Aug  3 14:28:55 2015
New Revision: 1693909

URL: http://svn.apache.org/r1693909
Log:
In the 1.9 release notes, document new server features.

* publish/docs/release-notes/1.9.html
  (#server-side-improvements): New section.

Modified:
    subversion/site/publish/docs/release-notes/1.9.html

Modified: subversion/site/publish/docs/release-notes/1.9.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.9.html?rev=1693909&r1=1693908&r2=1693909&view=diff
==============================================================================
--- subversion/site/publish/docs/release-notes/1.9.html (original)
+++ subversion/site/publish/docs/release-notes/1.9.html Mon Aug  3 14:28:55 2015
@@ -835,6 +835,71 @@ command.</p>
 
 </div> <!-- cmdline -->
 
+<div class="h3" id="server-side-improvements">
+<h3>Server-side improvements
+  <a class="sectionlink" href="#server-side-improvements"
+     title="Link to this section">&para;</a>
+</h3>
+
+<div class="h4" id="fewer-ood-conditions">
+<h4>Committing the result of large merges
+  <a class="sectionlink" href="#fewer-ood-conditions"
+     title="Link to this section">&para;</a>
+</h4>
+
+<p>Out best practices suggest that projects should branch and merge
+at the project root level.  Each merge will then usually change the
+<tt>svn:mergeinfo</tt> property at the project base folder.  To commit
+that change, pre-1.9 servers require the client to have the latest
+version of that base folder.  Whenever there is a commit in that tree,
+its base folder will get a new revision as well, though.   Thus, in
+large, busy projects, it is likely that by the time a large merge commit
+would actually have reached its finalization phase, some other commit
+got through and the merge commit is rejected for being out of date.  
+</p>
+
+<p>Subversion 1.9 now allows to modify directory properties based on
+old revisions as long as the directory contents itself did no change.
+Directory contents changes would either be property changes,  added or
+removed entries.  Sub-tree or file contents changes no longer prevent
+the property change to go through.  Of course, true file and tree
+change conflicts will still result in out-of-date errors.
+</p>
+
+<p>This new behavior is not restricted to <tt>svn:mergeinfo</tt> changes
+but applies to any directory properties.  Changes to <tt>svn:ignore</tt>
+are another common scenario previously prone to update / commit /
+out-of-date races.
+</p>
+
+</div> <!-- fewer-ood-conditions -->
+
+<div class="h4" id="rate-limiting-svnserve">
+<h4>Rate limiting <tt>svnserve</tt>
+  <a class="sectionlink" href="#rate-limiting-svnserve"
+     title="Link to this section">&para;</a>
+</h4>
+
+<p>In threaded mode, <tt>svnserve</tt> starts one thread per network
+connection - potentially consuming a large mount of resources.
+Subversion 1.9 now uses a thread pool with a configurable minimum and
+maximum number of threads.  Use the command line options
+<tt>--min-threads</tt> and <tt>--max-threads</tt> if the defaults
+don't suite your needs.  Run <tt>svnserve --help</tt> to your
+system's defaults and whether the options are available at all.
+</p>
+  
+<div class="notice">
+  <p>Once there are more connections than threads, the threads will serve
+  incoming requests in a round-robin fashion.  If all those requests are
+  long-running reports like checkout or export, connections with waiting
+  requests may eventually time out.</p>
+</div>
+  
+</div> <!-- rate-limiting-svnserve -->
+
+</div> <!-- server-side-improvements -->
+
 <div class="h3" id="svnadmin-improvements">
 <h3><tt>svnadmin</tt> changes and improvements
   <a class="sectionlink" href="#svnadmin-improvements"