diff options
Diffstat (limited to 'debian/svn_1.8_releasenotes.html')
| -rw-r--r-- | debian/svn_1.8_releasenotes.html | 2747 |
1 files changed, 0 insertions, 2747 deletions
diff --git a/debian/svn_1.8_releasenotes.html b/debian/svn_1.8_releasenotes.html deleted file mode 100644 index 22d288d..0000000 --- a/debian/svn_1.8_releasenotes.html +++ /dev/null @@ -1,2747 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" - "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"> -<head> -<title>Apache Subversion 1.8 Release Notes</title> -<meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> -<base href="https://subversion.apache.org"/> -<style type="text/css"> - @import url("/style/site.css"); -</style> -</head> - -<body> -<div id="site-banner"> -<div style="float: right; width: 379px; height: 80px; font-style: italic; - text-align: center;"> - <a href="https://www.apache.org/" - ><img src="/images/apache-logo.png" - alt="Apache Software Foundation" /></a> -</div> -<a href="/"> - <img src="/images/svn-square.jpg" - alt="[S]" - style="width: 80px; height: 80px;"/> - <img src="/images/svn-name-banner.jpg" - alt="Subversion" - style="width: 320px; height: 80px;"/></a> -</div> <!-- #site-banner --> - -<div id="site-nav"> -<div id="site-nav-menu"> -<ul> - <li>About Subversion - <ul> - <li><a href="/news.html">News</a></li> - <li><a href="/features.html">Features</a></li> - <li><a href="/docs/">Documentation</a></li> - <li><a href="/faq.html">FAQ</a></li> - <li><a href="/roadmap.html">Roadmap</a></li> - <li><a href="/security/">Security</a></li> - <li><a href="/quick-start">Quick Start</a></li> - </ul> - </li> - <li>Getting Subversion - <ul> - <!-- The ?update= parameter is used to only offer mirrors that have - synced after the specified date. We update it after a security - release when the email announcement is less than 24 hours after - the upload to /dist/release, in order to prevent offering mirrors - that don't carry the just-released artifacts. --> - <li><a href="/download.cgi?update=201708081800">Source Download</a></li> - <li><a href="/packages.html">Binary Packages</a></li> - <li><a href="/docs/release-notes/">Release Notes</a></li> - </ul> - </li> - <li>Community - <ul> - <li><a href="/mailing-lists.html">Mailing Lists</a></li> - <li><a href="/reporting-issues.html">Reporting Issues</a></li> - <li><a href="https://cwiki.apache.org/confluence/display/SVN/">Wiki</a></li> - <li><a href="/contributing.html">Getting Involved</a></li> - </ul> - </li> - <li>About the <acronym title="Apache Software Foundation">ASF</acronym> - <ul> - <li><a class="linkaway" - href="https://www.apache.org/licenses/">Licenses</a></li> - <li><a class="linkaway" - href="https://www.apache.org/foundation/sponsorship.html">Donate</a></li> - <li><a class="linkaway" - href="https://www.apache.org/foundation/thanks.html">Thanks</a></li> - </ul> - </li> -</ul> -</div> <!-- #site-nav-menu --> - -<div id="site-search"> - <form action="https://www.google.com/search" method="get" - style="margin-top: 10px; margin-bottom: 10px; display: inline;"> - <div style="display: inline;"> - <input value="subversion.apache.org" name="sitesearch" type="hidden" /> - <input name="q" id="query" type="text" placeholder="Search..." - style="width: 10em" - /> - <input name="Search" value="Go" type="submit"/> - </div> - </form> -</div> <!-- #site-search --> - -<div id="site-svnbook-block"> -<p>Read the official Subversion - documentation <a href="http://svnbook.org" class="linkaway">online</a>!</p> -<p><a href="http://svnbook.org/" - ><img src="/images/svnbook-cover.jpg" - alt="Version Control With Subversion"/></a></p> -</div> <!-- #site-svnbook-block --> - -<div id="copyright"> -<p>Copyright © 2018 <a href="https://www.apache.org/">The Apache - Software Foundation</a>, Licensed under - the <a href="https://www.apache.org/licenses/LICENSE-2.0" >Apache - License, Version 2.0</a>. Apache, Apache Subversion, and - the Apache feather logo are trademarks of The Apache Software - Foundation. Subversion and the Apache Subversion logo are - registered trademarks of The Apache Software Foundation.</p> -</div> <!-- #copyright --> - -</div> <!-- #site-nav --> - -<div id="site-content"> -<div id="site-notice"> - -<!-- PUT SITE-WIDE NOTICES HERE AS NECESSARY --> - -</div> <!-- #site-notice --> - -<!-- **************** BEGIN CONTENT ***************** --> - -<h1 style="text-align: center">Apache Subversion 1.8 Release Notes</h1> - -<div class="h2" id="news"> -<h2>What's New in Apache Subversion 1.8 - <a class="sectionlink" href="#news" - title="Link to this section">¶</a> -</h2> - -<ul> - <li><a href="#moves" - >Working copy records moves as first-class operation</a></li> - <li><a href="#auto-reintegrate" - >Automatic reintegration merge</a></li> - <li><a href="#iprops" - >Inherited properties</a></li> - <li><a href="#repos-dictated-config" - >Repository dictated configuration</a></li> - <li><a href="#neon-deleted" - >HTTP client support based on neon has been removed</a></li> - <li><a href="#bdb-deprecated" - >The Berkeley DB-based repository back-end has been deprecated</a></li> - <li><a href="#gpg-agent" - >In-memory password caching via GnuPG Agent (<em>Unix client</em>)</a></li> - <li><a href="#fsfs-enhancements" - >FSFS size and performance enhancements</a></li> - <li><a href="#in-repo-authz" - >Storage of authz files in the repository</a></li> - <li><a href="#new-tools" - >New tools for administrators and infrastructure</a></li> - <li><a href="#enhancements" - >Many enhancements and bug fixes</a></li> - <li><a href="#issues" - >Known issues in the release</a></li> -</ul> - -<p>Apache Subversion 1.8 is a superset of all previous Subversion -releases, and is as of the time of its release considered the current -"best" release. Any feature or bugfix in 1.0.x through 1.7.x is also -in 1.8, but 1.8 contains features and bugfixes not present in any -earlier release. The new features will eventually be documented in a -1.8 version of the free Subversion book -(<a href="http://svnbook.red-bean.com/" >svnbook.red-bean.com</a>).</p> - -<p>This page describes only major changes. For a complete list of -changes, see the 1.8 section of the <a -href="https://svn.apache.org/repos/asf/subversion/trunk/CHANGES" >CHANGES</a> -file.</p> - -</div> <!-- news --> - -<div class="h2" id="compatibility"> -<h2>Compatibility Concerns - <a class="sectionlink" href="#compatibility" - title="Link to this section">¶</a> -</h2> - -<p>Older clients and servers interoperate transparently with 1.8 -servers and clients. However, some of the new 1.8 features may not be -available unless both client and server are the latest version. There are -also cases where a new feature will work but will run less efficiently if -the client is new and the server old.</p> - -<p>There is <strong>no need</strong> to <a href="http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate.svnadmin" ->dump and reload</a> your repositories. -Subversion 1.8 servers can read and write to repositories created by -earlier versions. To upgrade an existing server installation, just install the -newest libraries and binaries on top of the older ones.</p> - -<p>Subversion 1.8 maintains API/ABI compatibility with earlier -releases, by only adding new functions, never removing old ones. A -program written to any previous 1.x API can both compile -and run using 1.8 libraries. However, a program written for 1.8 -cannot necessarily compile or run against older libraries.</p> - -<p>There may be limited cases where the behavior of old APIs has been -slightly modified from previous releases. These are cases where edge cases -of the functionality has been deemed buggy, and therefore improved or removed. -Please consult the -<a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.8/" ->API errata</a> for more detailed information on what these APIs are -and what impact these changes may have.</p> - -<div class="h3" id="new-feature-compatibility-table"> -<h3>New Feature Compatibility Table - <a class="sectionlink" href="#new-feature-compatibility-table" - title="Link to this section">¶</a> -</h3> -<table border="1"> - <tr> - <th>New Feature</th> - <th>Minimum Client<sup>1</sup></th> - <th>Minimum Server</th> - <th>Minimum Repository</th> - <th>Notes</th></tr> - <tr> - <td><a href="#moves">working copy records moves</a></td> - <td>1.8</td> - <td>any</td> - <td>any</td> - <td></td></tr> - <tr> - <td><a href="#auto-reintegrate">Automatic reintegration merge</a></td> - <td>1.8</td> - <td>1.5</td> - <td>1.5</td> - <td></td></tr> - <tr> - <td><a href="#neon-deleted">neon support removed</a></td> - <td>1.8</td> - <td>any</td> - <td>any</td> - <td><a href="#neon-deleted">Server-side configuration changes</a> - might be required for optimal performance with 1.8 clients which - access the repository via HTTP.</td></tr> - <tr> - <td><a href="#iprops">Inheritable properties</a></td> - <td>1.8</td> - <td>any</td> - <td>any</td> - <td>A 1.8 server isn't required but will deliver superior performance - when asked for inherited properties.</td></tr> - <tr> - <td><a href="#repos-dictated-config">Repos dictated config props</a></td> - <td>1.8</td> - <td>any</td> - <td>any</td> - <td></td></tr> - <tr> - <td><a href="#gpg-agent">Password caching with gpg-agent</a></td> - <td>1.8</td> - <td>any</td> - <td>any</td> - <td></td></tr> - <tr> - <td><a href="#fsfs-enhancements">FSFS enhancements</a></td> - <td>any</td> - <td>1.8</td> - <td>1.8</td> - <td><a href="#fsfs-deltification">Repository size reduction</a> - requires <a href="http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate.svnadmin" - >dump/load</a>.</td></tr> - <tr> - <td><a href="#in-repo-authz">Authz file in repository</a></td> - <td>any</td> - <td>1.8</td> - <td>any</td> - <td></td></tr> - <tr> - <td colspan="5"><sup>1</sup>Reminder: when using the <tt>file://</tt> - repository access method, the Subversion program is both the client - <em>and</em> the server.</td></tr> -</table> - -</div> <!-- new-feature-compatibility-table --> - -<div class="h3" id="wc-upgrade"> -<h3>Upgrading the Working Copy - <a class="sectionlink" href="#wc-upgrade" - title="Link to this section">¶</a> -</h3> - -<p>Subversion 1.8 introduces changes to the working copy format. -In previous releases of Subversion (1.6 and earlier), Subversion would -automatically upgrade the working copy to the new format when a write -operation was performed. Subversion 1.8, however, requires an upgrade for -both read and write operations on the working copy, and makes the upgrade -a manual step.</p> - -<p>Before using Subversion 1.8 with existing working copies, users will be -required to run the <tt>svn upgrade</tt> command to upgrade working copy -metadata to the new format. This command may take a while, and for some users, -it may be more practical to simply checkout a new working copy.</p> - -<p><strong>Note:</strong> Subversion 1.8 cannot upgrade working copies that -a 1.6 -or older- client would have refused to operate upon before an -<tt>svn cleanup</tt> -was run (with a 1.6 -or older- client). In other words, before upgrading to -1.8, an older client must be used to run <tt>svn cleanup</tt> on all working -copies that require cleanup. Likewise, Subversion 1.8 cannot upgrade corrupt -some 1.6 working copies. Unfixable problems can arise from missing or corrupt -meta-data inside <tt>.svn</tt> directories. Such damage to the 1.6 working -copy is permanent, and cannot be fixed even if <tt>svn cleanup</tt> is run -prior to the upgrade.</p> - -<p>If your working copy does not upgrade cleanly, please check out a new one. -</p> - -</div> <!-- wc-upgrade --> - -<div class="h3" id="output-changes"> -<h3>Command Line Output Changes - <a class="sectionlink" href="#output-changes" - title="Link to this section">¶</a> -</h3> - -<p>Although we try hard to keep output from the command line programs -compatible between releases, new information sometimes has to be -added. This can break scripts that rely on the exact format of the -output. For this reason, we encourage programs which consume the output -of the commandline client to consider using the <tt>--xml</tt> option, -or accessing Subversion through the various bindings interfaces.</p> - -<!-- Insert items here, of the following form: -<div class="h4" id="foo"> -<h4>Improved output of <tt>svn foo</tt> - <a class="sectionlink" href="#foo" - title="Link to this section">¶</a> -</h4> - -<p>The output of <tt>svn foo</tt> has been improved. The following -example illustrates these changes.</p> - -<pre> - $ svn foo - BAR - BAZ - BLAH - BIN - $ -</pre> - -</div> ---> - -<div class="h4" id="svn-mergeinfo"> -<h4>Improved output of <tt>svn mergeinfo</tt> - <a class="sectionlink" href="#svn-mergeinfo" - title="Link to this section">¶</a> -</h4> - -<p>The default output of <tt>svn mergeinfo</tt> has been changed. Instead -of being equivalent to <tt>svn mergeinfo --show-revs=merged</tt>, it now -shows a diagrammatic summary of some information about merges between the -two specified branches:</p> -<pre> -$ svn mergeinfo ^/subversion/branches/moves-scan-log - youngest common ancestor - | last full merge - | | tip of branch - | | | repository path - - 1186287 1445648 - | | - --| |------------ subversion/branches/moves-scan-log - / / - / / - -------| |------------ subversion/trunk - | | - 1241413 1445640 -$ -</pre> - -<p>Scripts using <tt>svn mergeinfo</tt> without a <tt>--show-revs=</tt> -option should be updated to add <tt>--show-revs=merged</tt>.</p> - -</div> - -<div class="h4" id="svn-proplist-propget"> -<h4>New options for <tt>svn proplist</tt> and <tt>svn propget</tt> - <a class="sectionlink" href="#svn-proplist-propget" - title="Link to this section">¶</a> -</h4> - -<p>The default output for these commands remains the same, but both -support the new option <tt>--show-inherited-props</tt> which may produce -output changes from 1.7.x. See <a href="#iprops">inheritable properties</a> -for more information.</p> - -</div> - -<div class="h4" id="svnlook-proplist-propget"> -<h4>Improved output and new options for <tt>svnlook proplist</tt> and <tt> - svnlook propget</tt> - <a class="sectionlink" href="#svnlook-proplist-propget" - title="Link to this section">¶</a> -</h4> - -<p>The output of <tt>svnlook proplist</tt> and -<tt>svnlook proplist --verbose</tt> has changed and now mimics the output -of <tt>svn proplist</tt> and <tt>svn proplist --verbose</tt> respectively. -<tt>svnlook propget</tt> now supports the <tt>--verbose</tt> option, which -produces output similar to <tt>svn propget --verbose</tt>.</p> - -<p>Both <tt>svnlook proplist</tt> and <tt>svnlook propget</tt> now support the -new option <tt>--show-inherited-props</tt> which may produce output changes -from 1.7.x. See <a href="#iprops">inheritable properties</a> -for more information.</p> - -</div> - -<div class="h4" id="svn-status-info-moves"> -<h4><tt>svn status</tt> and <tt>svn info</tt> now show local moves - <a class="sectionlink" href="#svn-status-info-moves" - title="Link to this section">¶</a> -</h4> - -<p><tt>svn status</tt> now shows moves in its output. -See the <a href="#moves">section about local moves</a> for more information.</p> - -<p><tt>svn status</tt> shows an extra line for each item involved in a move:</p> -<pre>$ svn move epsilon/zeta zeta-moved -$ svn status -D epsilon/zeta - <b>> moved to zeta-moved</b> -A + zeta-moved - <b>> moved from epsilon/zeta</b> -$ -</pre> - -<p><tt> svn info</tt> shows extra lines for locally moved items, too. -For example, if the file <tt>beta</tt> was moved to <tt>beta-new</tt>, -<tt>svn info beta</tt> will show the following (some unrelated output -has been omitted in this example):</p> -<pre> -$ svn info beta -Path: beta -[...] -Schedule: delete -<b>Moved To: beta-new</b> -[...] -</pre> - -</div> - -<div class="h4" id="svn-info"> -<h4><tt>svn info</tt> now shows repository-relative URLs - <a class="sectionlink" href="#svn-info" - title="Link to this section">¶</a> -</h4> - -<tt>svn info</tt> now includes repository-relative URLs of items -in the working copy in its output. -The command line client has been -<a href="/docs/release-notes/1.6.html#repository-root-relative-urls" ->accepting this URL notation since Subversion 1.6</a>. - -<pre>$ svn info README -Path: README -Name: README -Working Copy Root Path: /tmp/svn-trunk -URL: https://svn.apache.org/repos/asf/subversion/trunk/README -<b>Relative URL: ^/subversion/trunk/README</b> -Repository Root: https://svn.apache.org/repos/asf -Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 -Revision: 1467597 -Node Kind: file -Schedule: normal -Last Changed Author: danielsh -Last Changed Rev: 1242804 -Last Changed Date: 2012-02-10 15:58:53 +0100 (Fri, 10 Feb 2012) -Text Last Updated: 2012-09-20 01:33:22 +0200 (Thu, 20 Sep 2012) -Checksum: a27c71319a591c4eebe2bb81129413947336a7c6 -</pre> - -</div> - -</div> <!-- output-changes --> - -<div class="h3" id="neon-deleted"> -<h3>HTTP client support based on neon has been removed - <a class="sectionlink" href="#neon-deleted" - title="Link to this section">¶</a> -</h3> - -<p>HTTP client support based on <a href="http://webdav.org/neon">neon</a> -has been removed in favor of HTTP client support based on -<a href="https://serf.apache.org/">serf</a>.</p> - -<p>serf is a high-performance HTTP client library which has formed the basis -of an alternative HTTP repository access method for many years. -In an effort to decrease the development burden of maintaining multiple -HTTP client interfaces (and sets of bugs!) serf is now the only HTTP -client provider for Subversion.</p> - -<div class="notice"> -<p>Note that -<a href="https://svn.haxx.se/dev/archive-2011-01/0320.shtml" ->server-side configuration changes</a> might be required to avoid -performance regressions for serf clients in some setups.</p> -<p>The <strong>MaxKeepAliveRequests</strong> option in <tt>httpd.conf</tt> -needs to be increased from 100 (the default) to <b>at least</b> 1000 -(there is no reason why it could not be 10000). -This will improve performance by allowing serf clients to use fewer -TCP connections to the server. -Clients using neon will also work fine with this configuration.</p> -</div> - -<div class="h4" id="serf-skelta-default"> -<h4>Skelta style updates are now the default - <a class="sectionlink" href="#serf-skelta-default" - title="Link to this section">¶</a> -</h4> - -<p>The svn 1.8 client with serf defaults to skelta mode for update -operations (checkout, update, merge and export) instead of the bulk update mode -used by previous versions. Skelta mode was introduced in Subversion 1.6.0 and -improved in 1.8.0. It uses one HTTP request and response per resource that needs -to be fetched from the server, whereas bulk update mode fetches all resources in -one massive response.</p> - -<p>The main benefit of skelta mode is that it allows a correctly set up Apache -server or intermediate proxy server to cache <tt>mod_dav_svn</tt>’s responses to -handle later requests from the cache. This results in improved performance of -svn client operations and reduced CPU usage on the server side. It also allows -a more detailed audit of clients accessing resources in a Subversion -repository.</p> - -<p>Skelta mode has some disadvantages:</p> -<ul> -<li>Apache server access log files will grow more quickly due to the larger -number of requests and responses. As of 1.7.3, the httpd error logs may also -grow more rapidly with serf clients than with neon clients; see -<a href="https://svn.apache.org/viewvc?rev=1239697&view=rev" ->r1239697</a>.</li> -<li>Network traffic can increase drastically when Kerberos or NTLM -authentication is used, as these add a 2 - 4 KB header per HTTP request and -response.</li> -</ul> - -<p>This release introduces two options to control if the svn client will use -skelta or bulk update mode.</p> -<ul> -<li>For the server administrator: The <tt>SVNAllowBulkUpdates</tt> directive for -<tt>mod_dav_svn</tt> now accepts <tt>Prefer</tt>. This will advise the svn -client to always use bulk update mode. All svn client versions with a default -configuration (see table) will respect this preference.</li> - -<li>For the user: Set the new option <tt>http-bulk-updates</tt> in the servers -runtime configuration file to <em>yes</em> to force the use of bulk updates, -<em>no</em> to never use bulk updates. The default option <em>auto</em> makes -svn use skelta mode with a 1.8 server (unless it has <tt>SVNAllowBulkUpdates</tt> -set to <tt>Prefer</tt>), and bulk updates mode with -older servers and 1.8 servers which prefer bulk updates.</li> -</ul> - -<p>Table explaining the mode used between each combination of svn client and -server version and relevant configuration directives:</p> - -<table border="1"> - <tr> - <th></th> - <th colspan="3">1.8 Server<br/>with SVNAllowBulkUpdates:</th> - <th colspan="2">1.7 and older Server<br/>with SVNAllowBulkUpdates:</th> - </tr> - <tr> - <th>Subversion Client</th> - <th>Off</th> - <th>On<sup>*</sup></th> - <th>Prefer</th> - <th>Off</th> - <th>On<sup>*</sup></th> - </tr> - <tr> - <td>1.8, <tt>http-bulk-updates: auto</tt><sup>*</sup></td> - <td>Skelta mode</td> - <td>Skelta mode</td> - <td>Bulk mode</td> - <td>Skelta mode</td> - <td>Bulk mode</td> - </tr> - <tr> - <td>1.8, <tt>http-bulk-updates: yes</tt></td> - <td>Skelta mode</td> - <td>Bulk mode</td> - <td>Bulk mode</td> - <td>Skelta mode</td> - <td>Bulk mode</td> - </tr> - <tr> - <td>1.8, <tt>http-bulk-updates: no</tt></td> - <td>Skelta mode</td> - <td>Skelta mode</td> - <td>Skelta mode</td> - <td>Skelta mode</td> - <td>Skelta mode</td> - </tr> - <tr> - <td>1.7 and older with neon<sup>*</sup></td> - <td>Skelta mode</td> - <td>Bulk mode</td> - <td>Bulk mode</td> - <td>Skelta mode</td> - <td>Bulk mode</td> - </tr> - <tr> - <td>1.7 and older with serf</td> - <td>Skelta mode</td> - <td>Skelta mode</td> - <td>Skelta mode</td> - <td>Skelta mode</td> - <td>Skelta mode</td> - </tr> -</table> -<p><sup>*</sup>Default configuration</p> - -</div> <!-- serf-skelta-default --> - -</div> <!-- neon-deleted --> - -<div class="h3" id="bdb-deprecated"> -<h3>The Berkeley DB-based repository back-end has been deprecated - <a class="sectionlink" href="#bdb-deprecated" - title="Link to this section">¶</a> -</h3> - -<p>The Subversion developers have decided to <em>deprecate</em> the -repository back-end based on Berkeley DB. We simply do not have the -necessary resources to continue developing two distinct repository -back-ends. Instead, we will concentrate our efforts on improving FSFS -with new features, robustness and performance and architectural -enhancements.</p> - -<div class="h4" id="bdb-deprecated-means"> -<h4>What this means: - <a class="sectionlink" href="#bdb-deprecated-means" - title="Link to this section">¶</a> -</h4> -<ul> -<li>New repository features that may appear in future versions of -Subversion will not be implemented for the BDB back-end, -nor will we make any effort to improve its performance.</li> -<li>We will fix bugs and -security issues that may be found.</li> -<li>At some point, support for the BDB back-end will be completely -removed. We will announce such removal well in advance of its -happening.</li> -</ul> -</div> <!-- bdb-deprecated-means --> - -<div class="h4" id="bdb-deprecated-does-not-mean"> -<h4>What this <em>does not</em> mean: - <a class="sectionlink" href="#bdb-deprecated-does-not-mean" - title="Link to this section">¶</a> -</h4> -<ul> -<li>Users do not have to immediately migrate their repositories to -FSFS. The BDB back-end will continue to work, and will receive as -much test coverage as it has until now.</li> -</ul> -</div> <!-- bdb-deprecated-does-not-mean --> - -<p>This being a volunteer project, we are of course always happy -to accept contributions towards maintaining the Berkeley DB -back-end.</p> - -<div class="h4" id="bdb-deprecated-changes"> -<h4>User-visible changes - <a class="sectionlink" href="#bdb-deprecated-changes" - title="Link to this section">¶</a> -</h4> -<p>The only visible effect of the deprecation is that the -<code>svnadmin</code> utility will print a warning when it -creates a new Berkeley DB-based repository.</p> -</div> <!-- bdb-deprecated-changes --> - -</div> <!-- bdb-deprecated --> - -<div class="h3" id="compat-misc"> -<h3>Miscellaneous Compatibility Notes - <a class="sectionlink" href="#compat-misc" - title="Link to this section">¶</a> -</h3> - -<p>There are some additional specific areas where changes made in this -release might necessitate further adjustment by administrators or -users. We'll cover those in this section.</p> - -<div class="h4" id="authz-fspath-syntax"> -<h4>FS paths syntax in authz access rules - <a class="sectionlink" href="#authz-fspath-syntax" - title="Link to this section">¶</a> -</h4> - -<p>Prior to this release, the section headers in Subversion's authz -access files—which contain repository names and repository -filesystem paths—accepted section headers that would never be -looked up, because the repository filesystem path (such as -<tt>/trunk/secretdir</tt>) embedded in the section header is formatted -differently from how Subversion formats those paths when it looks them -up in the file. Subversion 1.7 and earlier would silently ignore -those sections of the authz file; directives in those sections would -never apply.</p> - -<p>That's been fixed in this release: Subversion will now -error out if a section header contains a repository filesystem path that -begins with a character other than slash (<tt>/</tt>), -contains two consecutive slashes, -or ends with a slash. -The practical fallout, though, is -that your existing authz files might be depending (perhaps -unintentionally) on the old behavior and the new behavior could result -in <em>all</em> access to items in your repositories being unexpectedly -<!-- it's not possible for access to be granted as a result of this -change, unless a failure to parse the authz file results in access -for everyone... which would not be a sane way to configure a server. --> -denied as a result of upgrading to Subversion -1.8. The <a -href="#svnauthz" ->svnauthz</a> tool, when linked to Subversion 1.8 -libraries, can be used to test an authz file for validity using the validate -subcommand. (The tool will error out on a file that the Subversion server will -error out on.)</p> - -</div> <!-- authz-fspath-syntax --> - -<div class="h4" id="repos-listing-authz-support"> -<h4>Repository listing now honors authz configuration - <a class="sectionlink" href="#repos-listing-authz-support" - title="Link to this section">¶</a> -</h4> - -<p>When Apache is configured with the <code>SVNParentPath</code> -directive, the "Collection of Repositories" list will now be filtered -based on read access to the root of each repository. Previously, all -repositories were included in the list even if navigating to a -repository would be forbidden. The "Collection of Repositories" will -now be consistent with the directory lists within repositories.</p> - -<p>NOTE: Access to "Collection of Repositories" is <em>not</em> -restricted by mod_authz_svn, but is instead managed by mod_dav_svn -itself. In order to require authentication on this location, the -location should have "Satisfy All" (which is the default value of this -directive). See examples in mod_authz_svn's <a -href="https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_authz_svn/INSTALL" ->INSTALL</a> document for additional details.</p> - -</div> <!-- repos-listing-authz-support --> - -<div class="h4" id="verify-issue4129"> -<h4>FSFS 'svnadmin verify' finds mergeinfo-count and predecessor-count discrepancies - <a class="sectionlink" href="#verify-issue4129" - title="Link to this section">¶</a> -</h4> - -<p>Up to 1.7.0, Subversion could create erroneous metadata on nodes in a -FSFS-backed repository in certain situations involving concurrent commit -attempts. (Only <em>metadata</em> was affected; file contents and properties -was not.) As of 1.7.1 Subversion -<!-- r1303070 --> -prevents new instances of the corruption, but -only as of 1.8.0 does 'svnadmin verify' -<!-- r1304656 --> -detect instances of that corruption in the history of a repository.</p> - -<p>The fix to these issues is simple: perform a <a -href="http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate.svnadmin" ->dump/load cycle</a>. (As usual, svnsync can be used instead of dump/load.) -The cycle can be done with any version of Subversion, and after the cycle the -repository should be served exclusively by Subversion 1.7.5 or newer to prevent -further instances of the bug from entering the repository.</p> - -<p>See <a href="../issue4129">this summary of issue #4129</a> for more information -about these problems.</p> - -</div> <!-- verify-issue4129 --> - -<div class="h4" id="client-cert-prompt-suppression"> -<h4>Client prompting for SSL client certificates - <a class="sectionlink" href="#client-cert-prompt-suppression" - title="Link to this section">¶</a> -</h4> - -<p>Subversion has long supported the use of SSL client certificates -for authentication against a server which accepts such. Users -typically employ the <code>ssl-client-cert-file</code> option in their -'servers' runtime configuration file to inform the client regarding -the location of the relevant certificate file. In interactive -scenarios, Subversion can also prompt the user for the location of the -certificate file when that runtime-configured value isn't set or -otherwise suitable.</p> - -<p>Prior to 1.8.0, this prompting was enabled by default. -Unfortunately, not every server which accepts client certificates -also <em>requires</em> them. Some users were being prompted for -client certificate file locations in scenarios where no certificate -was required (or perhaps even available). So in Subversion 1.8.0, the -Subversion client defaults to <em>not</em> prompting for the location -of an SSL client certificate file unless the user has set the new -<code>ssl-client-cert-file-prompt</code> runtime configuration -option (found in the <code>[auth]</code> section of the 'config' file) -to "yes".</p> - -<p>See <a href="https://issues.apache.org/jira/browse/SVN-2410">issue -#2410</a> for discussion and details.</p> - -</div> <!-- client-cert-prompt-suppression --> - -<div class="h4" id="swig-py-star"> -<h4>Star-imports in the SWIG-Python bindings - <a class="sectionlink" href="#swig-py-star" - title="Link to this section">¶</a> -</h4> - -<p>The swig-py bindings have been changed to make <tt>*</tt>-imports -of submodules to do the right thing: -<tt>from svn.client import *</tt> will now import only symbols beginning with -<tt>svn_</tt> or <tt>SVN_</tt>. (Most of these symbols will be -<tt>svn_client_*</tt> symbols, of course.) Star-imports of <tt>from svn</tt> have -not changed (they import <a -href="https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/python/svn/core.py" ->just the bare submodule names</a>: 'fs', 'ra', etc), and -star imports of <tt>from svn.core</tt> currently imports some select symbols -(notably 'Pool' and 'SubversionException').</p> - -<p>This change is incompatible: code that expected symbols such as 'commit_txn' -(in 'fs') and 'apr_initialize' to be pulled by a star-import will have to change.</p> - -</div> <!-- swig-py-star --> - -<div class="h4" id="svnserve-config-file"> -<h4>svnserve --config-file behavior with password and authz dbs - <a class="sectionlink" href="#svnserve-config-file" - title="Link to this section">¶</a> -</h4> - -<p>The behavior of the <tt>--config-file</tt> option to svnserve has changed. -The password db and authz db files will be reloaded on each connection. In past -versions these files were cached on startup when <tt>--config-file</tt> was -used.</p> - -<p>The svnserve.conf file directly passed to <tt>--config-file</tt> will still -be cached. Provided that the locations you wish to use for the authz and -password dbs have not changed, you will not need to restart svnserve in order to -have the changes you make to these files applied. This makes the behavior of -<tt>--config-file</tt> more consistent with configurations that do not use this -option.</p> - -<p>If you were depending on the configuration changes not being applied until -you restarted svnserve you will need to adjust accordingly.</p> - -</div> <!-- svnserve-config-file --> - -<div class="h4" id="svnauthz"> -<h4>svnauthz-validate renamed to svnauthz - <a class="sectionlink" href="#svnauthz" - title="Link to this section">¶</a> -</h4> - -<p>The svnauthz-validate command has been renamed to svnauthz and now has -a 'validate' subcommand. Meaning the equivalent to <tt>svnauthz-validate -file</tt> in 1.8 is <tt>svnauthz validate file</tt>. To maintain command -line compatibility, if the svnauthz command is run with the command name of -<tt>svnauthz-validate</tt> then it emulates the behavior of the -<tt>svnauthz-validate</tt> command from 1.7. <tt>make install-tools</tt> -installs a symlink <tt>svnauthz-validate</tt> to provide this compatibility -functionality.</p> - -<p>svnauthz also provides new functionality. -See <a href="#svnauthz_accessof">this section</a> for details.</p> - -</div> <!-- svnauthz --> - -</div> <!-- compat-misc --> - -</div> <!-- compatibility --> - -<div class="h2" id="new-features"> -<h2>New Features - <a class="sectionlink" href="#new-features" - title="Link to this section">¶</a> -</h2> - -<div class="h3" id="moves"> -<h3>Working copy records moves as first-class operation - <a class="sectionlink" href="#moves" - title="Link to this section">¶</a> -</h3> - -<p>The effect of the <tt>svn move</tt> command is now different -from running <tt>svn copy</tt> followed by <tt>svn delete</tt>. -Moves are represented within the working copy as a copy and a delete which -are linked to one another. -These links are shown by <tt>svn status</tt> and <tt>svn info</tt>.</p> - -<p>Some Subversion operations will now treat locally moved files and directories -specially. Behavioural changes include:</p> -<ul> - <li><p><tt>svn move</tt> now refuses to move a - <a href="http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs" - >mixed-revision working copy</a>.</p></li> - <li><p><tt>svn commit</tt> will only commit a moved file or directory - if both sides of the move are part of the same commit. This ensures - that moves are an atomic operation upon future updates and merges.</p></li> - <li><p><tt>svn update</tt>, <tt>svn switch</tt>, and <tt>svn resolve</tt> - can now resolve tree conflicts involving locally moved files or - directories. By picking the 'mine-conflict' option at the conflict - prompt, the update or switch operation can be applied to the new location - of the moved file or directory, which resolves the tree conflict and - allows the move to be committed. It is also possible to break a move - instead of updating it, in which case the move becomes a copy which - is no longer linked to a deletion.</p></li> -</ul> - -<p>Limitations:</p> -<ul> - <li><p>Moves are recorded as such only within the working copy. The link - between the copy and the delete is established only when a local move - operation is performed, and is lost upon commit. The committed revision - will show a copy and a delete, instead of a move.</p></li> -</ul> - -<p>Known issues:</p> -<ul> - <li><p>Tree conflicts involving replacements are currently - not detected when updating a moved file or directory (see <a - href="https://issues.apache.org/jira/browse/SVN-4318" - >issue #4318</a>).</p></li> - <li><p>Tree conflicts flagged by <tt>svn merge</tt> cannot be automatically - resolved yet. This will be addressed in a future release.</p></li> -</ul> - -</div> <!-- moves --> - -<div class="h3" id="auto-reintegrate"> -<h3>Automatic reintegration merge (--reintegrate option deprecated) - <a class="sectionlink" href="#auto-reintegrate" - title="Link to this section">¶</a> -</h3> - -<p>During merges which merge all eligible revisions from another -branch, Subversion 1.8 will automatically decide whether or not -the merge is <a -href="http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate" ->reintegrating a branch</a>. -Therefore, reintegrating a branch does no longer require the -<tt>--reintegrate</tt> option for correct operation.</p> - -<p>The <tt>--reintegrate</tt> option of <tt>svn merge</tt> is now -deprecated and its use is discouraged. To reintegrate a branch, -have a clean working copy of trunk and run the following command -in its top-level directory:</p> - -<pre>$ svn merge ^/branches/my-branch</pre> - -<p>This merge will still perform similar sanity checks which -<tt>svn merge --reintegrate</tt> performed in earlier releases: -<ul> -<li>The working copy must not be a <a -href="http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs" ->mixed-revision working copy</a>.</li> -<li>The working copy must not have <a -href="http://svnbook.red-bean.com/en/1.7/svn.branchmerge.switchwc.html" ->switched subtrees</a>.</li> -<li>There must be no gaps in revision ranges merged from the reintegration -target (e.g. the trunk) to the reintegration source (i.e. the branch to be -reintegrated).</li> -</ul></p> - -<p>If any of these conditions are detected, the merge is aborted and -the necessary steps must be taken to fix the problem before the -branch can be reintegrated. -In contrast to a <tt>--reintegrate</tt> merge, an automatic reintegration -merge into a working copy with local modifications is allowed.</p> - -<p>Merging to-and-fro between two branches in any order is possible -using the automatic reintegration merge (the "<a -href="http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice" ->keep-alive dance</a>" is no longer necessary). - -For best results, it is recommended to -always merge all eligible revisions, i.e. not using the -<tt>-r</tt> or <tt>-c</tt> options of <tt>svn merge</tt>. -Merging just a subset of eligible revisions increases the -likelihood of problems during future merges.</p> - -<p>Using <tt>--reintegrate</tt> in Subversion 1.8 will force a -reintegration merge, whether or not that's the right merge to perform -in the given situation.</p> - -</div> <!-- auto-reintegrate --> - -<div class="h3" id="iprops"> -<h3>Inherited Properties - <a class="sectionlink" href="#iprops" - title="Link to this section">¶</a> -</h3> - -<p>Property inheritance provides a mechanism to find the versioned -properties set on the <em>parents</em> of a given working copy or -URL path. Conversely it can be viewed as a mechanism by which a -versioned property set on a path also applies to that path's -children.</p> - -<p>It is important to note that this change <b>does not</b> introduce -any such thing as an "inheritable" property. Any versioned property, -explicitly set on a path, can be interpreted as inheritable by that -path's children. No changes have been made to the ways in which -properties are set or what valid property names and values are permitted. -Nor does this change grant access to parent paths which a user doesn't -have read access to. If a user has no read access to a parent path, he -cannot inherit properties from that parent.</p> - -<p>Other than the changes detailed <a href="#repos-dictated-config" ->below</a>, the only user visible changes resulting from inheritable -properties are to the <tt>svn proplist</tt>, <tt>svn propget</tt>, -<tt>svnlook proplist</tt>, and <tt>svnlook propget</tt> subcommands -when used with the new <tt>--show-inherited-props</tt> option.</p> - -<p>This new option finds the explicit properties set on a given path's -parent(s) lists them prior to the explicit properties on the target path -itself. For example:</p> - -<pre> - > svn propget -vR --show-inherited-props tsvn:logwidthmarker ^/subversion/trunk/subversion/po - <b>Inherited properties</b> on 'https://svn.apache.org/repos/asf/subversion/trunk/subversion/po', - from 'https://svn.apache.org/repos/asf/subversion/trunk': - tsvn:logwidthmarker - 78 - Properties on 'https://svn.apache.org/repos/asf/subversion/trunk/subversion/po': - tsvn:logwidthmarker - 80 -</pre> - -<p>If a working copy is the target, some properties may be inherited -from the working copy and some may be inherited from repository parent -paths not present in the working copy. These are shown as inherited -from a URL:</p> - -<pre> - > svn propget -vR --show-inherited-props tsvn:logwidthmarker po-wc\de.po - <b>Inherited properties</b> on 'po-wc\de.po', - from 'https://svn.apache.org/repos/asf/subversion/trunk': - tsvn:logwidthmarker - 78 - <b>Inherited properties</b> on 'po-wc\de.po', - from 'po-wc': - tsvn:logwidthmarker - 80 -</pre> - -<p>The output with the <tt>--xml</tt> option also returns inherited -properties, wrapping them in <tt>inherited_property</tt> rather than -<tt>property</tt> tags:</p> - -<pre> - > svn propget --show-inherited-props --xml tsvn:logwidthmarker ^/subversion/trunk/subversion/po - <?xml version="1.0" encoding="UTF-8"?> - <properties> - <target - path="https://svn.apache.org/repos/asf/subversion/trunk"> - <<b>inherited_property</b> - name="tsvn:logwidthmarker">78</inherited_property> - </target> - <target - path="https://svn.apache.org/repos/asf/subversion/trunk/subversion/po"> - <property - name="tsvn:logwidthmarker">80</property> - </target> - </properties> -</pre> - -<p>The <tt>svnlook proplist</tt> and <tt>svnlook propget</tt> subcommands -also support the new <tt>--show-inherited-props</tt> option. The output -is similar to <tt>svn proplist --show-inherited-props</tt> and -<tt>svn propget --show-inherited-props</tt> except that the paths are not -working copy paths or URLs, but absolute repository paths:</p> - -<pre> - > svnlook propget asf-repos-mirror tsvn:logwidthmarker /subversion/trunk/subversion/po \ - --show-inherited-props -v - <b>Inherited properties</b> on '/subversion/trunk/subversion/po', - from '/subversion/trunk': - tsvn:logwidthmarker - 78 - Properties on '/subversion/trunk/subversion/po': - tsvn:logwidthmarker - 80 -</pre> - -<p>Subversion working copies maintain a cache of the properties that the -root of the working copy inherits from its parent(s) in the repository. -This cache is updated each time you checkout, update, or switch a working -copy. This cache allows the working copy to access properties inherited -from the repository without contacting the repository.</p> - -<p>For the full details about inheritable properties see the -<a href="https://cwiki.apache.org/confluence/display/SVN/InheritedProperties" ->design wiki</a>. Some of this wiki is intended for Subversion developers -and will be of little interest to most users. If you fall into the latter -group you can focus on these particular sections:</p> - -<ul> - <li> - <a href="https://cwiki.apache.org/confluence/display/SVN/InheritedProperties#InheritedProperties-Differentiating'Inheritable'Vs.'Normal'Properties"> - Differentiating 'Inheritable' Vs. 'Normal' Properties</a> - </li> - <li> - <a href="https://cwiki.apache.org/confluence/display/SVN/InheritedProperties#InheritedProperties-GeneralInheritanceRules"> - General Inheritance Rules</a> - </li> - <li> - <a href="https://cwiki.apache.org/confluence/display/SVN/InheritedProperties#InheritedProperties-RepositoryInheritanceRules"> - Repository Inheritance Rules</a> - </li> - <li> - <a href="https://cwiki.apache.org/confluence/display/SVN/InheritedProperties#InheritedProperties-WorkingCopyInheritanceRules"> - Working Copy Inheritance Rules</a> - </li> - <li> - <a href="https://cwiki.apache.org/confluence/display/SVN/InheritedProperties#InheritedProperties-Authentication"> - Authentication</a> - </li> - <li> - <a href="https://cwiki.apache.org/confluence/display/SVN/InheritedProperties#InheritedProperties-SubcommandChanges"> - Subcommand Changes</a> - </li> -</ul> - -</div> <!-- iprops --> - -<div class="h3" id="repos-dictated-config"> -<h3>Repository Dictated Configuration (<em>For auto-props and ignores</em>) - <a class="sectionlink" href="#repos-dictated-config" - title="Link to this section">¶</a> -</h3> - -<p>Two new Subversion reserved properties, <tt>svn:auto-props</tt> -and <tt>svn:global-ignores</tt> make use of the new -<a href="#iprops">inherited properties</a> feature to provide additional -configuration information that overrides/extends some of the settings -found in the user's <a href="http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea.opts.config" ->runtime configuration</a>. The <tt>svn:auto-props</tt> -property overrides/extends the <tt>auto-props</tt> configuration setting. -The <tt>svn:global-ignores</tt> property extends the -<tt>global-ignores</tt> configuration setting as well as the -<tt>svn:ignore</tt> property.</p> - -<p>The <a href="https://cwiki.apache.org/confluence/display/SVN/Inheritable-Ignores-AutoProps#Inheritable-Ignores-AutoProps-Auto-PropsFormat" ->format</a> of <tt>svn:auto-props</tt> property values -is the same as for the <tt>auto-props</tt> runtime configuration. -The <a href="https://cwiki.apache.org/confluence/display/SVN/Inheritable-Ignores-AutoProps#Inheritable-Ignores-AutoProps-IgnoresFormat" ->format</a> of <tt>svn:global-ignores</tt> property values is the -same as for the <tt>svn:ignore</tt> property.</p> - -<p>Both properties work just like their analogs in the runtime -configuration with two exceptions:</p> - -<ul> - <li>The new properties only effect the subtrees rooted at the path - on which the property is set. Thus a given path may be affected - by multiple <tt>svn:auto-props</tt> or <tt>svn:global-ignores</tt> - properties set on different parents of that path.</li> - <li>The <tt>svn:auto-props</tt> property is not tied to the - <tt>enable-auto-props</tt> runtime configuration option. So even - if you have <tt>enable-auto-props=no</tt> set in your configuration - or via the <tt>--config-option</tt> option, <tt>svn:auto-props</tt> - are still applicable. Note however, that exactly like the runtime - configuration and <tt>svn:ignore</tt> property, both the - <tt>svn:auto-props</tt> and <tt>svn:global-ignores</tt> properties - can be disregarded with the <tt>--no-ignore</tt> and - <tt>--no-auto-props</tt> options respectively.</li> -</ul> - -<p>When multiple <tt>svn:global-ignores</tt> properties apply to a -path, then the different values are appended to any runtime -<tt>global-ignores</tt> in effect and the value of any <tt>svn:ignore</tt> -property that applies to the path.</p> - -<p>Patterns defined in <tt>svn:auto-props</tt> property -override any identical patterns in the <tt>auto-props</tt> runtime -config. When multiple <tt>svn:auto-props</tt> properties -apply to a file, the pattern from the nearest inheritable property takes -precedence. See <a href="https://cwiki.apache.org/confluence/display/SVN/Inheritable-Ignores-AutoProps#Inheritable-Ignores-AutoProps-Auto-PropsHierarchyandPrecedence" ->this section of design wiki</a> for a full explanation.</p> - -<p>The <a href="https://cwiki.apache.org/confluence/display/SVN/Inheritable-Ignores-AutoProps#Inheritable-Ignores-AutoProps-Auto-PropsHierarchyandPrecedence" ->design wiki</a> for the repository dictated configuration feature was -originally written for developers, but will prove useful to any repository -administrator who wants to use the feature.</p> - -</div> <!-- repos-dictated-config --> - -<div class="h3" id="gpg-agent"> -<h3>In-memory password caching via GnuPG Agent (<em>Unix client</em>) - <a class="sectionlink" href="#gpg-agent" - title="Link to this section">¶</a> -</h3> - -<p>Subversion 1.8 allows the use of the GnuPG Agent (gpg-agent) daemon -to temporarily store Subversion passwords in memory.</p> - -<p>This feature does <em>not</em> use PGP to encrypt passwords on disk! -Rather, it caches passwords in memory (in plaintext) instead of saving -them to disk.</p> - -<p>To take advantage of this password cache, you'll need Subversion binaries -built with gpg-agent support (which is the default on UNIX-like systems), -the gpg-agent itself, and a suitable pinentry program which the gpg-agent -will use to ask the user for the password. -The gpg-agent must be running, and the Subversion client will -need the <tt>GPG_AGENT_INFO</tt> and <tt>GPG_TTY</tt> environment -variables set up correctly. -See <a href="https://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html">this page</a> for more information about -running the gpg-agent.</p> - -<p>Cached passwords will persist in memory until the agent process -is terminated, its configured time-to-live threshold is reached, or a -HUP signal is sent to the daemon using the UNIX <tt>kill(1)</tt> utility.</p> - -<p>Communication to the gpg-agent happens over a UNIX socket, which is -located in a directory which only the user running Subversion can access. -However, any program the user runs could access this socket and get -the Subversion password if the program knows the "cache ID" Subversion -uses for the password.</p> - -<p>The cache ID is very easy to obtain for programs running as the same user. -Subversion uses the MD5 of the realmstring as cache ID, and these checksums -are also used as filenames within <tt>~/.subversion/auth/svn.simple</tt>. -Unlike with GNOME Keyring or KDE Wallet, the user is not prompted for -permission if another program attempts to access the password.</p> - -<div class="notice"> -<p><span style="color: red"><b>WARNING:</b></span> Therefore, while the -gpg-agent is running and has the password cached, the password cache -is no more secure than a file storing the password in plaintext.</p> -</div> - -</div> <!-- gpg-agent --> - -<div class="h3" id="fsfs-enhancements"> -<h3>FSFS size and performance enhancements - <a class="sectionlink" href="#fsfs-enhancements" - title="Link to this section">¶</a> -</h3> - -<p>Subversion 1.8 introduces a number of improvements that can reduce -the size of FSFS repositories, the total number of files on disk, the -I/O overhead and gives the user fine-grained control over all of that. -Some of these changes require a format bump, others are backward-compatible. -</p> - -<div class="h4" id="fsfs-format-6"> -<h4>FSFS format bump - <a class="sectionlink" href="#fsfs-format-6" - title="Link to this section">¶</a> -</h4> - -<p>The default repository format created by <tt>svnadmin create</tt> is -now FSFS version 6 which is not accessible by Subversion 1.7 or older. -Older repository formats remain fully supported by Subversion 1.8 but -will not support <a href="#revprop-packing">revprop packing</a>. -To create FSFS repositories compatible with Subversion 1.6 and 1.7, use -the <tt>--compatible-version 1.6</tt> parameter.</p> - -<p>You may use <tt>svnadmin upgrade</tt> to upgrade existing repositories. -However, to fully benefit from the latest <a href="#fsfs-deltification">repository size reductions</a>, -it is recommended to create a new repository, adjust its settings and then -<a href="http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate.svnadmin" ->dump/load</a> or svnsync the contents into it. -</p> - -<div class="notice"> - <p><span style="color: red"><b>WARNING:</b></span> <b>Server restart - required!</b> Replacing an existing repository with one rebuilt from a - dump or restored from backup requires a server restart. This is true for - any repository format. Alternatively, you may store the new repository in - a different directory and redirect the Apache configuration to use that - instead of the old one; <tt>svnserve</tt> does not offer that option.</p> -</div> - -</div> <!-- fsfs-format-6 --> - -<div class="h4" id="revprop-packing"> -<h4>Packing revision properties - <a class="sectionlink" href="#revprop-packing" - title="Link to this section">¶</a> -</h4> - -<p><a href="#fsfs-format-6">Format 6 repositories</a> will not only -pack the revision files but also the revision property files. Upgrading -existing packed repositories will automatically pack existing revision -properties. Using default settings, this will reduce the number of -revprop files to less than 10 per 1000 revisions in typical usage -scenarios.</p> - -<p>The <tt>db/fsfs.conf</tt> file allows you to fine-tune the -revprop packing strategy. See the comments in that file for a -detailed description of the available options. Please note that no -change in this configuration file will affect any existing data. -Moreover, upgrading repositories will not extend the existing -configuration file, i.e. the server will use the default settings -unless the new options are added explicitly.</p> - -<p>It is recommended to also activate <a href="#revprop-caching" ->revprop caching</a> when you use revprop packing. Otherwise, access -to timestamps etc. will suffer significant processing overhead.</p> - -</div> <!-- revprop-packing --> - -<div class="h4" id="revprop-caching"> -<h4>Caching revision properties - <a class="sectionlink" href="#revprop-caching" - title="Link to this section">¶</a> -</h4> - -<p>Many operations will access revision properties to e.g. retrieve -the commit time stamp. Therefore, thousands of revision property files -may need to be read during a checkout. The UI to enable the revprop -cache is similar to that for the other caches: <tt>svnserve</tt> -now accepts the <tt>--cache-revprops yes</tt> parameter. For -<tt>mod_dav_svn</tt>, the same looks like this in <tt>httpd.conf</tt> -</p> - -<pre> -<IfModule dav_svn_module> - SVNCacheRevProps on -</IfModule> -</pre> - -<p>With <a href="#revprop-packing">revision property packing</a> -enabled, revprop caching allows you to read hundreds of revprops -at once from a single file. This can give a significant performance -boost to e.g. <tt>svn log</tt> .</p> - -</div> <!-- revprop-caching --> - -<div class="h4" id="fsfs-deltification"> -<h4>Directory and property storage reduction - <a class="sectionlink" href="#fsfs-deltification" - title="Link to this section">¶</a> -</h4> - -<p>For each changed node in a FSFS repository, new versions of -all parent directories will be created. Larger repositories tend -to have relatively deep directory structures with at least one -level (branches, modules or projects) having tens of entries. -The total size of that data may well exceed the size of the actual -change. Subversion 1.8 now supports directory deltification -which eliminates most of that overhead.</p> - -<p>In <tt>db/fsfs.conf</tt>, you may now enable and disable -directory deltification at any time and these settings will be -applied in new revisions. For completeness, node properties may -now be deltified as well although the reductions in repository -size will usually be minimal.</p> - -<div class="notice"> - <p>By default, directory and property deltification are <em>disabled</em>. - You must edit <tt>db/fsfs.conf</tt> to enable these features. The reason - is that deltification may amplify I/O in certain situations. To minimize - that effect, enable the <a - href="/docs/release-notes/1.7.html#data-caches" - >txdelta cache</a>.</p> -</div> - -<p>Also, <tt>db/fsfs.conf</tt> now allows for fine-grained control over -how deltification will be applied. -See the comments in that file for a detailed description of the -individual options. -</p> - -<p>Another optimization in 1.8 is that node properties with the -same contents will only be stored once and then merely referenced. -This not only slightly reduces the size of the repository but greatly -improves cache effectiveness and may reduce I/O significantly. -</p> - -<p><b>It's backward compatible!</b> Please note that the mechanism -to read deltified data is the same for file contents as for directories -and properties. Hence, Subversion 1.6 and 1.7 will be able to read -them but will always write new revisions without that optimization. -It is therefore perfectly legal to create a pre-1.8-compatible -repository in 1.8, to enable various deltification options, to <a -href="http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate.svnadmin" ->dump/load</a> into that new repository using 1.8 tooling and to -finally use the repository with a 1.6 or 1.7 server. -</p> - -</div> <!-- fsfs-deltification --> - -<div class="h4" id="fsfs-rep-sharing"> -<h4>Rep-sharing within revisions - <a class="sectionlink" href="#fsfs-rep-sharing" - title="Link to this section">¶</a> -</h4> - -<p>When representation sharing has been enabled, Subversion 1.8 -will now be able to detect files and properties with identical contents -within the same revision and only store them once. This is a common -situation when you for instance import a non-incremental dump file or -when users apply the same change to multiple branches in a single commit. -</p> - -</div> <!-- fsfs-rep-sharing --> - -</div> <!-- fsfs-enhancements --> - -<div class="h3" id="in-repo-authz"> -<h3>In repository authz - <a class="sectionlink" href="#in-repo-authz" - title="Link to this section">¶</a> -</h3> - -<p>Subversion 1.8 allows authz files to be stored inside a Subversion -repository. This allows you to employ the versioning features of -Subversion for the configuration of the path-based authorization -feature. You need not store the authz file in the same repository as -the one to which its rules are being applied. However, the server -which uses the authz file does require filesystem access to the -repository in which that file is stored. Administrators should -consider that one benefit of having the authz file stored in the same -repository as the one to which its rules are being applied allows the -authz file to be replicated by <tt>svnsync</tt> along with the rest -of the data in the repository, simplifying administration of mirrored -repositories.</p> - -<p>When specifying the location of the authz file to Apache HTTP -Server or svnserve, there are now four formats an administrator may -use:</p> - -<ol> -<li>Absolute path to a file (outside of a repository): - <tt>/path/to/file</tt> or <tt>C:\path\to\file</tt></li> -<li>Relative path to a file (outside of a repository): - <tt>path/to/file</tt> or <tt>path\to\file</tt></li> -<li>Absolute URL to file in repository: - <tt>file:///path/to/repo/file</tt></li> -<li>Relative URL to file in a repository: - <tt>^/file</tt></li> -</ol> - -<p>The first two formats are those that were already supported in -versions prior to 1.8; the latter two are the new formats.</p> - -<p>The new absolute URL format is similar to what you might use -with <tt>svn cat</tt> to list the contents of a file versioned in a -local repository. (Note that at this time, support exists -for <tt>file://</tt> URLs only, not for other Subversion URL flavors -such as <tt>http://</tt>, <tt>svn://</tt>, and so on.)</p> - -<p>The relative URL syntax should also look familiar, as it mimics -<a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/cli-repo-root-relative-support.txt" ->the relative URL syntax</a> that the command-line client recognizes. -When parsing path specifications in this format, Subversion simply -ignores the leading <tt>^/</tt> and looks for authz file at the -remaining path in the repository which is being accessed.</p> - -<p>Apache HTTP Server accepts all four formats for both the -<tt>AuthzSVNAccessFile</tt> and <tt>AuthzSVNReposRelativeAccessFile</tt> -configuration directives. The only difference between these two -directives is the root path for the "relative path to a file outside a -repository" format.</p> - -<div class="notice"> -<p><span style="color: red"><b>WARNING:</b></span> Unlike authz files -stored on the server's local disk, authz files stored in the repository -are accessible via Subversion clients just like any other file in the -repository. If you wish to protect the contents of the authz file you -should configure appropriate access restrictions for it in the -applicable authz file (which could potentially be the same file!).</p> -</div> - -<div class="notice"> -<p><span style="color: red"><b>WARNING:</b></span> As with other -versioned files, Subversion servers do not validate the internal -syntax of a versioned authz file in any way. Administrators may wish -to set up a pre-commit hook script to validate that the authz file is -well-formed and/or the committing user has not removed all permissions -to edit the file. If permissions have been removed to edit it via the -network server(s) you can of course always edit it via a local -(<tt>file://</tt>) checkout since ra_local does not observe path based -permissions. See the <tt>validate-files.py</tt> hook script and its -related configuration files in Subversion's <tt>tools/hook-scripts</tt> -for examples of how to validate a versioned authz file's syntax and -specific permissions.</p> -</div> - -</div> <!-- in-repo-authz --> - -<div class="h3" id="new-tools"> -<h3>New tools and utilities - <a class="sectionlink" href="#new-tools" - title="Link to this section">¶</a> -</h3> - -<div class="h4" id="benchmarking"> -<h4><tt>svn-bench</tt> benchmarking client - <a class="sectionlink" href="#benchmarking" - title="Link to this section">¶</a> -</h4> - -<p>Identifying bottlenecks in your Subversion infrastructure may be -difficult because client-side influences (virus scanners, slow disks -etc.) tend to mask other limitations. Therefore, Subversion 1.8 -introduces a very lightweight client that skips most of that local -processing.</p> - -<p><tt>svn-bench</tt> provides commands similar to the standard -command line interface, adding a <tt>null-</tt> prefix to them. -Currently implemented are <tt>null-export</tt>, <tt>null-list</tt> -and <tt>null-log</tt>. They support most of the parameters of their -standard command counterparts.</p> - -<pre> -$ time svn-bench null-export svn://localhost/tsvn_repos/trunk - 179 directories - 3,661 files - 84,902,674 bytes in files - 20,560 properties - 315,031 bytes in properties - -real 0m0.185s -user 0m0.128s -sys 0m0.040s -</pre> - -<p>By running the client close to or directly on the server machine, -you will be able to determine the raw server speed and compare that -to what the client-side is seeing.</p> - -</div> <!-- benchmarking --> - -<div class="h4" id="fsfs-stats"> -<h4><tt>fsfs-stats</tt> repository statistics - <a class="sectionlink" href="#fsfs-stats" - title="Link to this section">¶</a> -</h4> - -<p>This server-side tool will read a whole format 4 (Subversion 1.6) -or newer repository and print out various statistics on the contents -of the rev and pack files in it. It starts of with very general -information and then breaks it down into various sub-demographics. -The statistics include: - -<ul> - <li>Total repository size bytes</li> - <li>Number of revisions and changes</li> - <li>Sum of original and deltified file sizes</li> - <li>Sum of original and deltified directory sizes</li> - <li>Structural overhead due to node revisions, change lists etc.</li> - <li>Effectiveness of representation sharing</li> - <li>Paths and revisions of the 64 largest single changes</li> - <li>By file extension: Number of changes, total file size and total - internal representation size</li> - <li>Histograms on the above</li> -</ul> -</p> - -<p>Administrators may use this information to decide whether directory -deltification should be enabled (ratio of directory representation -vs. file representation sizes) or whether commit policies might to -be revised (e.g. large .zip files accout for most of the repository). -Some of the data, however, is useful for performance analysis by SVN -developers only.</p> - -<pre> -$ fsfs-stats /repositories/wesnoth_org 500 | gedit & -</pre> - -<p><tt>fsfs-stats</tt> takes a local path to the repository root and -an optional cache size parameter. The latter is in MBytes and speeds -up the analysis of large repositories. Because the tool's output may -be up to a 1000 lines of text, you may want to redirect it to some file -or application.</p> - -<div class="notice"> -<p>Note that the 32 bit version of this tool may fail on repositories -with millions of changes or with revision / pack files larger than 4 GB. -Use a 64 bit executable instead for those repositories.</p> -</div> - -</div> <!-- fsfs-stats --> - -</div> <!-- new-tools --> - -</div> <!-- new-features --> - -<div class="h2" id="enhancements"> -<h2>Enhancements and Bugfixes - <a class="sectionlink" href="#enhancements" - title="Link to this section">¶</a> -</h2> - -<!-- Don't need to highlight every bugfix, just major ones which aren't in - any patch release. --> - -<div class="h3" id="conflicts"> -<h3>Improved conflict resolution - <a class="sectionlink" href="#conflicts" - title="Link to this section">¶</a> -</h3> - -<div class="h4" id="conflicts-postponed"> -<h4>Conflicts are now always postponed during updates and merges - <a class="sectionlink" href="#conflicts-postponed" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>svn update</tt>, <tt>svn switch</tt>, and <tt>svn merge</tt> -commands line client now always postpone conflicts. Once the operation has -completed, the interactive conflict resolver is automatically run on paths -which received conflicts during the operation, which will either run in -interactive mode or perform conflict resolution based on the value of -the <tt>--accept</tt> option, if given.</p> - -<p>This approach has the advantage that the connection to the server -is not held open while interactive conflict resolution is performed. -In Subversion 1.7, the connection could time out if the user spent -too much time resolving a conflict (see -<a href="https://issues.apache.org/jira/browse/SVN-3846" ->issue #3846</a>).</p> - -</div> <!-- conflicts-postponed --> - -<div class="h4" id="svn-resolve"> -<h4>'svn resolve' can resolve conflicts interactively - <a class="sectionlink" href="#svn-resolve" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>svn resolve</tt> command does not require the <tt>--accept</tt> -option anymore. If invoked without any arguments, <tt>svn resolve</tt> -will now perform interactive conflict resolution for any conflicted -paths within the current working directory.</p> - -</div> <!-- svn-resolve --> - -<div class="h4" id="file-merge-tool"> -<h4>Built-in file merge tool for interactive conflict resolution - <a class="sectionlink" href="#file-merge-tool" - title="Link to this section">¶</a> -</h4> - -<p>The command-line client now has a built-in file merge tool which -merges any non-conflicting changes automatically and asks the user -what to do about each individual merge conflict.</p> - -<p>The built-in file merge tool can be invoked from the interactive -conflict resolution prompt by choosing the <tt>(m) merge</tt> option. -It displays conflicting file sections in a side-by-side view and -offers various ways of resolving the conflict, as shown below:</p> - -<pre> -$ svn update -Updating '.': -C subversion/svn/file-merge.c -Updated to revision 1358165. -Summary of conflicts: - Text conflicts: 1 -Conflict discovered in file 'subversion/svn/file-merge.c'. -Select: (p) postpone, (df) diff-full, (e) edit, (m) merge, - (mc) mine-conflict, (tc) theirs-conflict, - (s) show all options: m -Merging 'subversion/svn/file-merge.c'. -Conflicting section found during merge. -(1) their version (at line 298) |(2) your version (at line 391) ---------------------------------------+-------------------------------------- - if (buf->len >= 2 && | if (buf->len > 1) - buf->data[buf->len - 2] == '\r' | { - buf->data[buf->len - 1] == '\n')| if (buf->data[buf->len - 2] == ' - svn_stringbuf_chop(buf, 2); | svn_stringbuf_chop(buf, 2); - else if (buf->len >= 1 && | } - (buf->data[buf->len - 1] ==| else if (buf->len > 0) - buf->data[buf->len - 1] ==| { - svn_stringbuf_chop(buf, 1); | if (buf->data[buf->len - 1] == ' - | svn_stringbuf_chop(buf, 1); - | } ---------------------------------------+-------------------------------------- -Select: (1) use their version, (2) use your version, - (e1) edit their version and use the result, - (e2) edit your version and use the result, - (eb) edit both versions and use the result, - (p) postpone this conflicting section leaving conflict markers, - (a) abort file merge and return to main menu: -</pre> -</div> <!-- file-merge-tool --> - -</div> <!-- conflicts --> - -<div class="h3" id="pristines"> -<h3>Checkout and update download pristine file data just once - <a class="sectionlink" href="#pristines" - title="Link to this section">¶</a> -</h3> - -<p>Subversion keeps a cache of pristine copies of files in the -working copy's meta data area inside the <tt>.svn</tt> directory. -Before Subversion 1.8, pristine data was always downloaded from -the server even if the same data already existed in the cache.</p> - -<p>Subversion 1.8 avoids downloading pristine content that is already -present in the cache, based on the content's SHA1 or MD5 checksum. -This results in more efficient use of network throughput in cases where -a lot of files in the working copy share the same content (for example, -if a single working copy contains multiple branches).</p> - -</div> <!-- pristines --> - -<div class="h3" id="cmdline-admin"> -<h3>Administration command-line tools improvements (<em>server</em>) - <a class="sectionlink" href="#cmdline-admin" - title="Link to this section">¶</a> -</h3> - -<div class="h4" id="incremental-hotcopy"> -<h4>'svnadmin hotcopy' can now operate incrementally (FSFS only) - <a class="sectionlink" href="#incremental-hotcopy" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>svnadmin hotcopy</tt> command now supports incremental -operation, triggered by the new <tt>--incremental</tt> option.</p> - -<p>In prior releases of Subversion, <tt>svnadmin hotcopy</tt> refused -to copy over an existing destination repository, and always copied -the entire repository. For large repositories, performing a hotcopy -could take several hours, preventing an efficient backup process.</p> - -<p>In incremental hotcopy mode, revision data which has already been -copied from the source to the destination repository will not be -copied again. <tt>svnadmin hotcopy --incremental</tt> will only copy -new revisions, and revisions which have changed in size or had their -modification time stamp changed since the previous hotcopy operation.</p> - -<p>Up to now, <tt>svnsync</tt> or <tt>svnadmin dump --incremental</tt> -were the only alternatives for incremental repository backup. However, -these commands need to perform additional processing while transforming -revision data into an intermediate format before creating revision -files in the destination repository. Performance of <tt>svnadmin -hotcopy</tt> is only limited by disk I/O.</p> - -<p>Incremental hotcopy is not supported for BDB repositories. -See <a href="https://issues.apache.org/jira/browse/SVN-4081" ->issue 4081</a> for more information.</p> - -<div class="notice"> -<p>Using general-purpose incremental backup tools, such as -<a href="https://rsync.samba.org/">rsync</a>, with Subversion repositories -is dangerous if the repository can receive commits while the backup -tool is running. The resulting copy might end up being corrupt because -general-purpose backup tools do not know anything about consistency -requirements of Subversion repositories. It is recommended to use -incremental hotcopy instead. Alternatively, if network support is -required for the backup procedure, <tt>svnsync</tt> should be used. -There is also a new <a href="#svnadmin-freeze">svnadmin freeze</a> command -which allows third-party tools to access a live repository safely.</p> -</div> - -</div> <!-- incremental-hotcopy --> - -<div class="h4" id="svnadmin-load"> -<h4>'svnadmin load' now supports the --revision option - <a class="sectionlink" href="#svnadmin-load" - title="Link to this section">¶</a> -</h4> - -<p><tt>svnadmin load</tt> now supports the <tt>--revision</tt> -(<tt>-r</tt>) option, which causes it to only load revisions from -the dump stream within the specified revision number range.</p> - -</div> <!-- svnadmin-load --> - -<div class="h4" id="svnadmin-lock"> -<h4>New 'svnadmin lock' and 'svnadmin unlock' commands - <a class="sectionlink" href="#svnadmin-lock" - title="Link to this section">¶</a> -</h4> - -<p>The new <tt>svnadmin lock</tt> and <tt>svnadmin unlock</tt> commands -can be used to lock and unlock paths in the repository directly, -without requiring a working copy for use with <tt>svn lock</tt> or -<tt>svn unlock</tt>.</p> - -</div> <!-- svnadmin-lock --> - -<div class="h4" id="svnadmin-freeze"> -<h4>New 'svnadmin freeze' command - <a class="sectionlink" href="#svnadmin-freeze" - title="Link to this section">¶</a> -</h4> - -<p>The new <tt>svnadmin freeze</tt> command can be used to run an arbitrary -program while preventing concurrent commits to the repository. The program -is invoked by <tt>svnadmin</tt> with a provided parameter list. This can -be used to safely use third-party backup tools on a live repository:</p> -<pre> -$ svnadmin freeze /svn/my-repos -- rsync -av /svn/my-repos /backup/my-repos -</pre> - -<p>The above will obtain a write lock on the <tt>my-repos</tt> repository -to prevent concurrent commits, and run -<a href="https://rsync.samba.org/">rsync</a> to back up the repository. -Clients trying to commit concurrently will wait until the write lock -becomes available again. If the command takes too much time clients -trying to commit might time out. It is recommended to run commands -which complete very quickly, such as a command to trigger creation -of a filesystem snapshot.</p> - -</div> <!-- svnadmin-freeze --> - -<div class="h4" id="svndumpfilter-deltas"> -<h4>'svndumpfilter' now supports dump files with deltas - <a class="sectionlink" href="#svndumpfilter-deltas" - title="Link to this section">¶</a> -</h4> - -<p><tt>svndumpfilter</tt> can now filter dump files containing -deltas, as generated by <tt>svnadmin dump --deltas</tt>.</p> - -</div> <!-- svndumpfilter-deltas --> - -<div class="h4" id="svnauthz_accessof"> -<h4>svnauthz can print user's access to a path in a repository - <a class="sectionlink" href="#svnauthz_accessof" - title="Link to this section">¶</a> -</h4> - -<p><tt>svnauthz</tt> (<a href="#svnauthz" ->formerly known as <tt>svnauthz-validate</tt></a>) -has an 'accessof' subcommand that can print or test what the -permissions would be in a given circumstance, allowing you to validate that -your changes have effected the permissions that you intended.</p> - -<p><tt>svnauthz accessof</tt> supports <tt>--username</tt>, -<tt>--repository</tt>, and <tt>--path</tt> arguments. -When these are passed, it prints <tt>no</tt>, <tt>r</tt>, -or <tt>rw</tt> depending on what access the given username has: -none, read-only, or read-write.</p> - -</div> <!-- svnauthz_accessof --> - -<div class="h4" id="svnlook-diff"> -<h4>'svnlook diff' improvements - <a class="sectionlink" href="#svnlook-diff" - title="Link to this section">¶</a> -</h4> - -<p><tt>svnlook diff</tt> now supports the following new options -(analogous to <tt>svn diff</tt>): -<ul> -<li><tt>--ignore-properties</tt> suppresses output of property changes</li> -<li><tt>--properties-only</tt> shows only property changes</li> -<li><tt>--diff-cmd ARG</tt> use ARG as diff command</li> -</ul> -</p> - -</div> <!-- svnlook-diff --> - -</div> <!-- cmdline-admin --> - -<div class="h3" id="svnserve"> -<h3>Support for high-speed networks in 'svnserve' - <a class="sectionlink" href="#svnserve" - title="Link to this section">¶</a> -</h3> - -<p>If your server has a 10 Gbit/s or faster network connection, the -multi-stage data copying from Subversion's caches to the network stack -plus frequent status checks become a bottleneck. Today, most clients -won't be able to generate enough aggregated traffic to make this an -issue and an 8-core server should be able to send about 40Gb/s at 100% -CPU load. Future clients may be able, however, to process 1Gb or even -10Gb per second and to create significant server loads. -</p> - -<p>When the server is given the <tt>--client-speed N</tt> parameter, -it will assume that most clients are able to process data at rates of -N Mbit/s; N being a non-negative integer. Future server releases may -apply different strategies for different ranges of client bandwidth -to optimize the network performance. In 1.8 and if N>=1000, the -server will take various shortcuts to reduce internal processing overhead. -On the downside, a very slow or hanging client may degrade the server -performance for other clients as well. Setting N to values above 100.000 -is legal but will often result in a net throughput loss. -</p> - -<p><strong>Note:</strong> This option will have little effect in 1.8 -without configuring large fulltext caches. -</p> - -</div> <!-- svnserve --> - -<div class="h3" id="cmdline"> -<h3>Command-line client improvements (<em>client</em>) - <a class="sectionlink" href="#cmdline" - title="Link to this section">¶</a> -</h3> - -<p>There are far too many enhancements and new options to the -command-line client to list them all here. Aside from all the ones -mentioned already in these release notes, below are a few more that we -consider important, but please see the 1.8.0 section in the <a -href="https://svn.apache.org/repos/asf/subversion/trunk/CHANGES">CHANGES</a> file -for a complete list.</p> - -<!-- Insert selected items here --> - -<div class="h4" id="commit-externals"> -<h4>'svn commit' can now recurse into externals - <a class="sectionlink" href="#commit-externals" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>svn commit</tt> command supports a new <tt>--include-externals</tt> -option, which causes it to commit changes within externals in the current -working copy, in addition to the changes in the current working copy. -This works by implicitly adding all externals within the commit target -to the list of commit targets.</p> - -</div> <!-- commit-externals --> - -<div class="h4" id="svn-diff"> -<h4>'svn diff' improvements - <a class="sectionlink" href="#svn-diff" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>svn diff</tt> command can compare arbitrary files with one -another, using the invocation:</p> -<pre> -$ svn diff --old foo.c --new bar.c -Index: bar.c -=================================================================== ---- bar.c (.../foo.c) (working copy) -+++ bar.c (.../bar.c) (working copy) -@@ -1,6 +1,6 @@ - #include <stdio.h> - int main() - { -- printf("Hello world!\n"); -+ printf("Good bye world!\n"); - return 0; - } -</pre> - -<p>This works with any combination of versioned and unversioned files. -Comparing arbitrary directories is also supported, in which case the -directories are walked recursively and files within them are compared.</p> - -<p><tt>svn diff</tt> also supports the following new options: -<ul> -<li><tt>--ignore-properties</tt> suppresses output of property changes</li> -<li><tt>--properties-only</tt> shows only property changes</li> -<li><tt>--patch-compatible</tt> produces output compatible with third party patch programs</li> -</ul> -</p> - -<p><tt>svn diff --summarize</tt> is extended to match all scenarios that -<tt>svn diff</tt> supports, including the new arbitrary file diff.</p> - -</div> <!-- svn-diff --> - -<div class="h4" id="svn-log-search"> -<h4>'svn log' can filter log messages based on search terms - <a class="sectionlink" href="#svn-log-search" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>svn log</tt> command supports a new <tt>--search</tt> -option that can be used to show only log messages matching any -of one or more provided search patterns. A log message is shown only -if a revision's author, date, log message text, or list of changed paths, -matches a search pattern.</p> - -<p>The log could be searched for revisions which deleted a particular -file, or more generally for revisions which affected a given file on -any branch in the repository:</p> -<pre>$ svn log -v --search "src/foo.c" http://svn.example.com/svn/</pre> - -<p>The new <tt>--search-and</tt> option can be used for grouping search -terms such that they must match together. -For example, when run in a working copy, the following command shows -log messages for revisions which were committed by (or otherwise match) -author <tt>james</tt> in September 2012:</p> -<pre>$ svn log --search james --search-and "Sep 2012"</pre> - -</div> <!-- svn-log-search --> - -<div class="h4" id="svn-merge-check-related"> -<h4>'svn merge' will refuse to merge from an unrelated branch - <a class="sectionlink" href="#svn-merge-check-related" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>svn merge</tt> command without a revision range -now checks that the source branch is related to the target branch, and -fails if not. Branches are 'related' if their histories, when traced -back following copies, eventually arrive at the same node. One useful -case is when an automatic merge is attempted from the wrong level of -subdirectory in an otherwise related branch. Example:</p> -<pre>$ svn merge ^/trunk branch-wc/subdir -svn: E205000: Source and target must be different but related branches -svn: E205000: Source and target have no common ancestor: 'https://.../trunk@head' and 'branch-wc/subdir@unspecified' -</pre> - -<p>It is still possible to merge from an unrelated branch by specifying a -revision range, even a catch-all range such as <tt>1:HEAD</tt>.</p> - -</div> <!-- svn-merge-check-related --> - -</div> <!-- cmdline --> - -<div class="h3" id="custom-keywords"> -<h3>Custom keyword definitions - <a class="sectionlink" href="#custom-keywords" - title="Link to this section">¶</a> -</h3> - -<p>Subversion now supports the definition of custom keywords, which can be -defined using a special syntax within the <tt>svn:keywords</tt> property.</p> - -<p>For example, <tt>MyKeyword=%r%_%a%_%P</tt> defines a keyword called -"MyKeyword" which contains the number of the last-changed -revision, the author of that revision, and the file's path in the -repository, each separated by one space character. -Once a custom keyword has been defined it can be used within the -file like any other keyword: <tt>$MyKeyword$</tt></p> - -<p>The <tt>svn help propset</tt> command lists the known format codes -which can be used in custom keyword definitions, which are also shown -in the table below. Any characters in the keyword definition which are -not format codes are expanded literally, i.e. a keyword such as -<tt>MyAuthor=Author:%_%a</tt> will expand to <tt>Author: joe</tt> -if the last-changed revision's author is "joe".</p> - -<table border="1"> -<tr> - <td>%a</td><td>The author of the revision given by %r.</td> -</tr> -<tr> - <td>%b</td><td>The basename of the URL of the file.</td> -</tr> -<tr> - <td>%d</td><td>Short format of the date of the revision given by %r.</td> -</tr> -<tr> - <td>%D</td><td>Long format of the date of the revision given by %r.</td> -</tr> -<tr> - <td>%P</td><td>The file's path, relative to the repository root.</td> -</tr> -<tr> - <td>%r</td><td>The number of the revision which last changed the file.</td> -</tr> -<tr> - <td>%R</td><td>The URL to the root of the repository.</td> -</tr> -<tr> - <td>%u</td><td>The URL of the file.</td> -</tr> -<tr> - <td>%_</td><td>A space (keyword definitions cannot contain a literal space).</td> -</tr> -<tr> - <td>%%</td><td>A literal '%'.</td> -</tr> -<tr> - <td>%H</td><td>Equivalent to %P%_%r%_%d%_%a.</td> -</tr> -<tr> - <td>%I</td><td>Equivalent to %b%_%r%_%d%_%a.</td> -</tr> -</table> - -<p>Note that keyword expansions which exceed 255 bytes in length are -truncated, and keywords with names that exceed 255 bytes are not expanded.</p> - -</div> <!-- custom-keywords --> - -<div class="h3" id="apis"> -<h3>API changes, improvements and language bindings - (<em>client and server</em>) - <a class="sectionlink" href="#apis" - title="Link to this section">¶</a> -</h3> - -<p>There are too many new and revised APIs in Subversion 1.8.0 to list -them all here. See the <a -href="/docs/api/1.8/" >Subversion API -Documentation</a> page for general API information. If you develop a -3rd-party client application that uses Subversion APIs, you should -probably look at the header files for the interfaces you use and see -what's changed.</p> - -<p>A small number of APIs have slightly changed functionality from their -historical roots. Each of these cases has been documented as an -<a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.8/">errata</a>, -detailing the impact of these changes. All of the errata were the result of -behavior which was deemed buggy, and the API changes are an attempt to fix -these bugs. The circumstances under which each is triggered are relatively -rare, and we anticipate the actual impact to end users will be minimal.</p> - -<p>Language bindings have mostly been updated for the new APIs, though -some may lag more than others.</p> - -</div> <!-- apis --> - -<div class="h3" id="bug-fixes"> -<h3>Bug fixes (<em>client and server</em>) - <a class="sectionlink" href="#bug-fixes" - title="Link to this section">¶</a> -</h3> - -<p>A great many bugs have been fixed. See the 1.8.0 section in the <a -href="https://svn.apache.org/repos/asf/subversion/trunk/CHANGES">CHANGES</a> file -for details.</p> - -</div> <!-- bug-fixes --> - - -<div class="h3" id="merge-tracking-enhancements"> -<h3>Merge-Tracking Enhancements - <a class="sectionlink" href="#merge-tracking-enhancements" - title="Link to this section">¶</a> -</h3> - -<p>While there are scores of bug fixes, performance improvements, and other -changes to merge-tracking, the following are the major changes. See the -1.8.0 section in the <a -href="https://svn.apache.org/repos/asf/subversion/trunk/CHANGES">CHANGES</a> -file for a complete list.</p> - -<div class="h4" id="mergeinfo-r"> -<h4>'svn mergeinfo' now honors the -r option - <a class="sectionlink" href="#mergeinfo-r" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>svn mergeinfo</tt> command now honors the <tt>-r</tt> option. -While the option has always been accepted and documented, it was silently -ignored, such that <tt>svn mergeinfo</tt> always operated on the entire -history of the repository.</p> - -<p>In Subversion 1.8, the <tt>-r</tt> option restricts the output of -<tt>svn mergeinfo</tt> to the specified revision range, which is useful -when determining whether or not a given revision, or range of revisions, -is eligible for merging, or whether it has already been merged. -In the following example, r682012 has not been merged from trunk yet, -while r26112011 has already been merged:</p> -<pre> - $ svn mergeinfo --show-revs=eligible -r 682012 ^/trunk - r682012 - $ svn mergeinfo --show-revs=merged -r 26112011 ^/trunk - r26112011 - $ -</pre> - -</div> <!-- mergeinfo-r --> - -</div> <!-- merge-tracking-enhancements --> - -<div class="h3" id="hooks"> -<h3>Hook scripts improvements (<em>server</em>) - <a class="sectionlink" href="#hooks" - title="Link to this section">¶</a> -</h3> - -<div class="h4" id="hooks-env"> -<h4>Hook script environment variables are now configurable - <a class="sectionlink" href="#hooks-env" - title="Link to this section">¶</a> -</h4> - -<p>In Subversion 1.7 and earlier, hook scripts always run in an empty -environment. If environment variables are needed hook scripts had to -configure them manually. Subversion 1.8 supports configuration of hook -script environment variables on a per-server or per-repository basis.</p> - -<p>The hook script environment is configured via a new configuration file -located either at <tt>conf/hooks-env</tt> in a repository, or at a -server-wide location specified in <tt>svnserve.conf</tt> (using the -new <tt>hooks-env</tt> option) or <tt>httpd.conf</tt> (using the -new <tt>SVNHooksEnv</tt> option).</p> - -<p>The hook script environment configuration file uses a format similar -to that of other Subversion configuration files:</p> -<pre> -### This file is an example hook script environment configuration file. -### Hook scripts run in an empty environment by default. -### As shown below each section defines environment variables for a -### particular hook script. The [default] section defines environment -### variables for all hook scripts, unless overridden by a hook-specific -### section. - -### This example configures a UTF-8 locale for all hook scripts, so that -### special characters, such as umlauts, may be printed to stderr. -### If UTF-8 is used with a mod_dav_svn server, the <a href="#mod-dav-svn-utf8">SVNUseUTF8</a> option must -### also be set to 'yes' in httpd.conf. -### With svnserve, the LANG environment variable of the svnserve process -### must be set to the same value as given here. -[default] -# LANG = en_US.UTF-8 - -### This sets the PATH environment variable for the pre-commit hook. -# [pre-commit] -# PATH = /usr/local/bin:/usr/bin:/usr/sbin -</pre> - -</div> <!-- hooks-env --> - -<div class="h4" id="mod-dav-svn-utf8"> -<h4><tt>mod_dav_svn</tt> now supports hook script UTF-8 input/output - <a class="sectionlink" href="#mod-dav-svn-utf8" - title="Link to this section">¶</a> -</h4> - -<p>As documented in <a -href="https://issues.apache.org/jira/browse/SVN-2487" ->issue #2487</a>, hook scripts run on a <tt>mod_dav_svn</tt>-based -Subversion server previously had problems with non-ASCII input and output. -Because Apache HTTPD modules always run in the "C" locale, -which is restricted to ASCII, <tt>mod_dav_svn</tt> usually failed -trying to process non-ASCII characters.</p> - -<p>Among other problems, this prevented <tt>pre-lock</tt> and -<tt>post-unlock</tt> hook scripts from operating on paths containing -non-ASCII characters, and prevented non-ASCII error output from -<tt>start-commit</tt> and <tt>pre-commit</tt> hooks from reaching -SVN clients.</p> - -<p>Subversion 1.8 addresses these problems with a new <tt>SVNUseUTF8</tt> -option for <tt>mod_dav_svn</tt>. If this option is set, <tt>mod_dav_svn</tt> -assumes that all hook script input/output is encoded in UTF-8. -This is always the case for paths passed to hook scripts, since Subversion -uses UTF-8 internally for all paths. If this option is set, hook scripts -<b>must</b> write error messages to stderr in UTF-8. Because ASCII is a -subset of UTF-8 existing hook scripts will continue to work unmodified.</p> - -<p>For best results, hook scripts should use a UTF-8 locale if the -<tt>SVNUseUTF8</tt> option is active. It is recommended to configure -a UTF-8 locale using the <a href="#hooks-env" ->hook script environment configuration file</a>.</p> - -</div> <!-- mod-dav-svn --> - -<div class="h4" id="hooks-start-commit"> -<h4><tt>start-commit</tt> hook invocation point changed - <a class="sectionlink" href="#hooks-start-commit" - title="Link to this section">¶</a> -</h4> - -<p>Prior to this release, the <tt>start-commit</tt> hook script was -invoked by Subversion just prior to the creation of the commit -transaction. An errorful return from the hook would be marshaled back -to the client without the commit transaction having ever been created. -A successful return would permit the creation of the commit -transaction, and allow the commit process to proceed as expected. -Administrators generally employed the <tt>start-commit</tt> hook to -immediately deny <em>all</em> commits to a repository, as the amount -of information available to the hook by which to do so -<em>conditionally</em> was pretty slim.</p> - -<p>Beginning with Subversion 1.8, the <tt>start-commit</tt> hook is -invoked immediately <em>after</em> Subversion creates the commit -transaction and sets its initial properties. This -allows <tt>start-commit</tt> implementations to examine the commit -transaction's properties (such as the revision log message and the new -<a href="#ephemeral-txnprops">ephemeral transaction properties</a>) -when deciding whether or not to allow the commit to proceed. -Subversion will abort the created transaction upon detecting an -errorful return from the hook and will, of course, still marshal that -error condition back to the client.</p> - -<p>This change empowers administrators to disallow certain commits via -the <tt>start-commit</tt> hook rather than doing so much later — -after the client's changes are transmitted across the network — -in the <tt>pre-commit</tt> hook. Imagine the frustration of a user -who has endured the lengthy upload of 2 Gb of commit data only to have -his or her commit bounced because of an insufficiently formatted log -message! These changes to <tt>start-commit</tt> allow the go/no-go -decision on such a commit to be made before that large commit payload -is transmitted across the wire.</p> - -<p><strong>Note:</strong> Subversion does not require that commit -transaction properties (such as the revision log message) be attached -to the transaction as part of its initialization. As such, some -clients will still not provide that information to the server until -after the <tt>start-commit</tt> hook has been invoked. Here is a list -of such clients we are aware of:</p> - -<ul> -<li>Pre-1.8 clients communicating via HTTP</li> -<li>Clients communicating via HTTP when mod_dav_svn's - "SVNAdvertiseV2Protocol" option has been set to "off"</li> -</ul> - -<p>Administrators should consider modularizing the tests that their -hooks perform on transaction properties, invoke those tests from both -the <tt>start-commit</tt> and <tt>pre-commit</tt> hook scripts.</p> - -</div> <!-- hooks-start-commit --> - -<div class="h4" id="hooks-post-commit"> -<h4><tt>post-commit</tt> hook grows <tt>txn-name</tt> argument - <a class="sectionlink" href="#hooks-post-commit" - title="Link to this section">¶</a> -</h4> - -<p>The <tt>post-commit</tt> hook has grown a <tt>txn-name</tt> argument as the -third positional argument (<tt>argv[3]</tt>). This argument is the name of the -transaction that has become the revision triggering the <tt>post-commit</tt> -hook; it is the same as the second positional argument to the -<tt>pre-commit</tt>, and thus enables the <tt>pre-commit</tt> and -<tt>post-commit</tt> hooks to easily transfer state between them.</p> - -<p>Generically, if the <tt>pre-commit</tt> hook makes an expensive computation -against the would-be-revision, it can store the result of that computation in a -persistent hash keyed by the transaction name, which the <tt>post-commit</tt> -hook will use to avoid re-doing the computation. One concrete usage of this -would be to implement a pre-commit hook that tests compilability only, while -a post-commit hook or a continuous integration tool runs more thorough tests ---- on the binaries built at pre-commit, without having to rebuild them -itself.</p> - -</div> <!-- hooks-post-commit --> - -<div class="h4" id="ephemeral-txnprops"> -<h4>Commit transactions now carry client information - <a class="sectionlink" href="#ephemeral-txnprops" - title="Link to this section">¶</a> -</h4> - -<p>Subversion 1.8 clients communicating to 1.8 servers -(via <tt>http[s]:</tt> or <tt>svn:</tt>) will now attach "ephemeral -transaction properties" to commit transactions which carry metadata -considered useful to server-side hook scripts. These special -properties are set on the commit transaction as early as possible -(generally prior to the invocation of -the <a href="#hooks-start-commit"><tt>start-commit</tt></a> hook, but -certainly prior to the invocation of the <tt>pre-commit</tt> hook), -and then automatically removed by Subversion just prior to the commit -transaction being promoted to a new revision.</p> - -<p>Currently, the following ephemeral transaction properties are -available to hook scripts for examination:</p> - -<ul> -<li><strong>svn:txn-user-agent</strong> - carries the "user agent" - string which describes the committing client program. (Developers - of third-party clients which link against the Subversion libraries - may modify the customizable portion of this string by implementing - the <tt>get_client_string()</tt> RA callback API which was - introduced in Subversion 1.5.)</li> -<li><strong>svn:txn-client-compat-version</strong> - carries the - Subversion library version string with which the connecting client - claims compatibility. (For Subversion clients which use the - Apache Subversion C API and libraries, this version is precisely - the version of those libraries.)</li> -</ul> - -<p><strong>Note:</strong> Administrators who deem the information -carried in these properties to be of long-term value may of course log -the information as they see fit. For example, such an administrator -may wish to use a <tt>pre-commit</tt> hook script -to copy the values of those -properties to new, custom transaction properties (which -do <em>not</em> have names within the reserved <tt>svn:</tt> -namespace, of course!) for long-term storage associated with the -commit. An example hook script that renames the revision properties from -<tt>svn:txn-*</tt> to <tt>svn:revision-*</tt> is -<a href="https://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/persist-ephemeral-txnprops.py?view=markup" ->distributed with Subversion itself</a>.</p> - -</div> <!-- ephemeral-txnprops --> - -</div> <!-- hooks --> - -<div class="h3" id="svnpubsub"> -<h3>New <tt>svnpubsub</tt> framework for pushing post-commit notifications - (<em>server</em>) - <a class="sectionlink" href="#svnpubsub" - title="Link to this section">¶</a> -</h3> - -<p><tt>svnpubsub</tt> is a daemon that pushes post-commit notifications to -clients in streaming JSON over HTTP. The notifications are typically -pushed to the daemon by a <tt>post-commit</tt> hook. The code lives in -the <a href="https://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svnpubsub/" ->tools/server-side/svnpubsub</a> directory of the source tree.</p> - -<p>A typical notification looks like this (newlines added for readability):</p> - -<pre> -% curl -i http://svn.foo.org:2069/commits -{"commit": { - "type": "svn", - "format": 1, - "id": 1334845, - "repository": "13f79535-47bb-0310-9956-ffa450edef68", - "changed": {"httpd/site/trunk/content/dev/": {"flags": " U "}}, - "committer": "joes", - "log": "spacing", - "date": "2012-05-07 00:30:25 +0000 (Mon, 07 May 2012)"}} -^@ -... -</pre> - -<p>svnpubsub was written by <a href="https://people.apache.org/~pquerna/" -rel="nofollow">Paul Querna</a> for the <a href="https://www.apache.org/dev/" ->ASF Infrastructure Team</a>.</p> - -</div> <!-- svnpubsub --> - -<div class="h3" id="svnmasterversion"> -<h3>New <tt>SVNMasterVersion</tt> Apache HTTP Server configuration directive - <a class="sectionlink" href="#svnmasterversion" - title="Link to this section">¶</a> -</h3> - -<p>Subversion's HTTP protocol continues to mature and expand over time -to support new features or better ways to accomplish things. -Fortunately, Subversion servers and clients happily negotiate which -bits of that protocol they both understand. Unfortunately, WebDAV -proxy configurations can throw this negotiation for a loop, as the -slave server does the negotiating but not necessarily all the -operating. Thus, a Subversion 1.7 WebDAV proxy slave will by default -tell the client that it's okay to use the <a href="./1.7.html#httpv2" ->HTTPv2 protocol</a>, and a Subversion 1.7 or better client will do -so, even if the <em>master</em> server behind the proxy is running -Subversion 1.6 and unable to understand the new protocol.</p> - -<p>When Subversion 1.7 was released, this specific problem was -addressed by providing an Apache HTTP Server configuration -directive — <tt>SVNAdvertiseV2Protocol</tt> — which allowed -administrators in such a scenario to "dumb down" the communications of -the Subversion 1.7 slave server so that connecting clients would use -the older protocol and, in doing so, not confuse the Subversion 1.6 -master server when requests were proxied to it. As development -continued toward 1.8, though, there where several new features and -protocol changes made which would likewise require a toggle switch -to avoid confusing pre-1.8 WebDAV proxy master servers.</p> - -<p>Rather than exposing a suite of such toggles — some of which -were for behaviors that are entirely specific to the protocol itself -and not tied to any user-visible feature — Subversion 1.8 allows -administrators to simply declare to the slave servers the version of -Subversion which is powering the master server, allowing the slave -servers to enable and disable features as makes sense for that -scenario. Administrators of Subversion deployments which use the -WebDAV write-through proxy feature are strongly encouraged to use the -new <tt>SVNMasterVersion</tt> httpd.conf directive in all slave server -configurations running Subversion 1.8 or better.</p> - -<p>For example, if your master server is running Subversion 1.7.7, your -Subversion 1.8 slave server's Apache HTTP Server configuration might -contain something like this:</p> - -<pre><Location /svn> -DAV svn -… -SVNMasterURI http://master.svn.company.com/svn -SVNMasterVersion 1.7.7 -… -</Location> -</pre> - -<div class="notice"> -<p>In the general case, the new <tt>SVNMasterVersion</tt> directive -supercedes the need for <tt>SVNAdvertiseV2Protocol</tt>. By declaring -the version of the master server, the slave will assume the default -level of feature support for that server. However, if you have a -master server which <em>can</em> support the HTTPv2 protocol but for -which you've disabled this intentionally, you will need to also -explicitly disable the feature (again, via -the <tt>SVNAdvertiseV2Protocol off</tt> directive) in your slave -servers as well.</p> -</div> - -</div> <!-- svnmasterversion --> - -<div class="h3" id="davkeywordexpansion"> -<h3>Keyword expansion via DAV repository browser - <a class="sectionlink" href="#davkeywordexpansion" - title="Link to this section">¶</a> -</h3> - -<p>One of the earliest features of the mod_dav_svn Subversion server -was the ability for users to browse their repositories directly with a -web browser. <tt>GET</tt> requests issued by browser and aimed at -Subversion directory URLs return a directory listing; those aimed at -file URLs return the file's current contents.</p> - -<p>In Subversion 1.6, we expanded that feature to allow browsing of -historical artifacts in your repository via -new <a href="/docs/release-notes/1.6.html#historical-uris" -><tt>p=<em>PEGREV</em></tt> and <tt>r=<em>REV</em></tt> CGI -parameters</a>.</p> - -<p>Now in Subversion 1.8, we've added still another CGI -parameter: <tt>kw=1</tt>.</p> - - <pre>http://host/repos/path?kw=1</pre> - -<p>Users who include <tt>kw=1</tt> in the query string portion -of <tt>GET</tt> requests aimed at a versioned file will now be -delivered that file's contents with any Subversion keywords expanded -therein. Because keyword substitution is typically performed by the -Subversion client as part of its working copy administration and -management, this is handy way to get the server to deliver a -keyword-expanded form of your versioned file without the use of a -working copy. Omitting the <tt>kw</tt> parameter or using something -other than "1" for its value will cause Subversion to use its default -behavior, which is to deliver the file's contents without any keywords -expanded. (NOTE: We reserve the right to recognize new meaningful -values for the <tt>kw</tt> flag in the future, so please avoid -specifying any value other than "1" when using the parameter at -all.)</p> - -<p>As with client-side keyword expansion, only those keywords which -are explicitly designated for expansion via the <tt>svn:keywords</tt> -property set on the file itself will be expanded.</p> - -</div> <!-- davkeywordexpansion --> - -<div class="h3" id="exclusivelocking"> -<h3>Exclusive SQLite locking of working copies - <a class="sectionlink" href="#exclusivelocking" - title="Link to this section">¶</a> -</h3> - -<p>In the root of every Subversion working copy there is an -<a href="https://sqlite.org/" >SQLite</a> database in the <tt>.svn</tt> -directory and Subversion clients use this database when accessing the -working copy. By default Subversion uses shared SQLite locking and -this allows simultaneous access to the working copy by multiple -clients with exclusive locks only being held for short periods. The -1.8 command line client can be configured to use exclusive SQLite -locking by setting the following in the <tt>.subversion/config</tt> -file:</p> -<pre> -[working-copy] -exclusive-locking-clients = svn -</pre> - -<p>or by using the command line option <tt>--config-option config:working-copy:exclusive-locking-clients=svn</tt>.</p> - -<p>This reduces the locking overhead but does mean that only one -Subversion client will be able to access the working copy at a time. A -second client attempting to access a locked working copy will block -for 10 seconds and then get an error. In most cases shared locking is -preferred but if the working copy is on a network disk rather than a -local disk the locking overhead is more significant. When dealing -with large working copies on network disks exclusive locking may give -a significant performance gain, two or three times faster in some -cases.</p> - -</div> <!-- exclusivelocking --> - -</div> <!-- enhancements --> - -<div class="h2" id="issues"> -<h2>Known issues in the release - <a class="sectionlink" href="#issues" - title="Link to this section">¶</a> -</h2> - -<p>There are some known issues in the Subversion 1.8 releases. These -may be fixed in later 1.8.x releases.</p> - -<div class="h3" id="411-length-required"> -<h3>1.8.0 and chunked Transfer-Encoding - <a class="sectionlink" href="#411-length-required" - title="Link to this section">¶</a> -</h3> - -<p>Subversion 1.8.0 has <a href="#neon-deleted">switched from <tt>neon</tt> -to <tt>serf</tt> for HTTP access</a>. The Serf-based HTTP access library would -use <tt>chunked</tt> transfer encoding for most requests. When the -<tt>mod_dav_svn</tt> Subversion server is fronted by a proxy or reverse proxy -(such as Nginx -prior to 1.3.9) which responds with a <tt>411 Length Required</tt>, Subversion -would sometimes either treat this as a fatal error, such as:</p> - -<pre> -% svn commit <arguments> -POST of '/svn/[project name]/!svn/me': 411 Length Required -</pre> - -<p>or</p> - -<pre> -svn: E175009: XML parsing failed: (411 Length Required) -</pre> - -<p>and sometimes would fail to notice the failure of the request and issue an -unrelated error, such as:</p> - -<pre> -svn: E175004: The PROPFIND response did not include the requested properties -</pre> - -<p>Subversion 1.8.1 fixes this issue by detecting automatically -whether <tt>chunked</tt> -requests are supported at the set up of a session. This is done -by issuing one additional request at the start of the session.</p> - -<!-- "Dangerous curve"; additional technical details not required for - understanding the context --> -<div class="notice" style="background-color: inherit"> -<p>Technical details: -A session is often equivalent to calling one <tt>svn</tt> subcommand (or -one <tt>svn_client_*</tt> function, for <a href="/docs/#release-1.8">API users</a>). -However several subcommands currently open multiple sessions. The extra -request cost is incurred for each session. A single session may make numerous -TCP connections (usually 2 and never more than 8) and the extra request will -only be made once for all the connections in a session.</p> - -<p>The net effect is that the cost of the additional request may be incurred -multiple times, and thus be more noticeable. For example <tt>svn log --diff</tt> -ends up opening 2 sessions for every revision in order to request the diff.</p> -</div> - -<p>We expect that the default configuration of Subversion 1.8.1+ will work well -out of the box for most users. A <tt>http-chunked-requests</tt> option has been -added to the <tt>~/.subversion/servers</tt> (Windows: -<tt>%APPDATA%\Subversion\servers</tt> file. Users who wish to avoid the -additional request may set that option to <tt>yes</tt> or <tt>no</tt> in order -to short-circuit the additional request and avoid making it. We recommend not -to set that option (or to set it to its default value, <tt>auto</tt>) unless -you have special circumstances which require it (such as an unusually high -latency), and even then to set it only in the config sections of specific -groups and not in the <tt>[global]</tt> section. See <a -href="https://mail-archives.apache.org/mod_mbox/subversion-dev/201307.mbox/%3cCADkdwvQUaWaC5=AvwsthjSQWcn48tKHVfWoVCUHjLT=Abu13YA@mail.gmail.com>">this dev@ list post</a> for an example.</p> - - -</div> <!-- 411-length-required --> - -<div class="h3" id="mod_dav_svn-fsmap"> -<h3>mod_dav_svn Maps Requests to Local Filesystem - <a class="sectionlink" href="#mod_dav_svn-fsmap" - title="Link to this section">¶</a> -</h3> - -<p>Prior to Subversion 1.7.12 and 1.8.2 all previous versions of -<tt>mod_dav_svn</tt> would allow Apache httpd to map requests handled by -<tt>mod_dav_svn</tt> to the local file system. When this happened httpd would -believe that it was serving a file or directory located at the path that -comprises the URI path appended to the <tt>DocumentRoot</tt> of the server but -ending at the first path component that does not actually exist on the local -disk. For example if your <tt>DocumentRoot</tt> was <tt>/var/www</tt> and you -were accessing <tt>/svn/repo/README</tt> and <tt>/var/www/svn</tt> did not -exist then httpd would believe it was serving <tt>/var/www/svn</tt>, but if -<tt>/var/www/svn</tt> existed while <tt>/var/www/svn/repo</tt> did not then -it would believe it was serving <tt>/var/www/svn/repo</tt>. This had several -undesired side effects.</p> - -<ul> - <li><tt><Directory></tt> blocks could match requests being served by - mod_dav_svn. This would allow directives applied in these configuration - blocks (most notably access control directives) to be applied.</li> - <li>When using Apache httpd 2.4.x and <tt>mod_dir</tt>, if a file from the - <tt>DirectoryIndex</tt> directive existed at the path Apache httpd believed - it was serving then the request would be rewritten to access that file, - which may or may not exist. If the path was the <tt>SVNParentPath</tt> - then SVN would try to access a repository with the name of the - <tt>DirectoryIndex</tt> file that was found.</li> - <li>When using the <tt>%f</tt> variable in your log directives you would log - the path constructed as described above. This was confusing since it was - not the content that was actually served.</li> -</ul> - -<p>Starting with Subversion 1.7.12 and 1.8.2 the requests being served by -<tt>mod_dav_svn</tt> will not be mapped to the local file system and when -logging with the <tt>%f</tt> variable you will see a <tt>"-"</tt> -logged. <tt><Directory></tt> blocks will no longer apply to such requests. -Subversion 1.7.14 and 1.8.5 changed this further and the filename for the request -will now be set as <tt>dav_svn:/path/to/repo/path/in/repo</tt> (e.g. if your repo is at -<tt>/var/svn/repo</tt> and the request is accessing <tt>/trunk/myfile</tt> in -the repo then the filename for the request will be set to -<tt>dav_svn:/var/svn/repo/trunk/myfile</tt>. Note that the dav_svn: prefix will -prevent the filename from matching an actual path on disk since it isn't a -valid path and as such <tt><Directory></tt> blocks will still not apply. -</p> - -<div class="notice"> -<p><span style="color: red"><b>WARNING:</b></span>Therefore, if you were -using <tt><Directory></tt> blocks to restrict access to paths served -by <tt>mod_dav_svn</tt> you will need to adjust your configuration. Since -the local filesystem path was not complete this never would have been very -useful for path based authorization, but it could be misused for simple -things like blocking an IP. These directives must be moved inside the -appropriate <tt><Location></tt> blocks.</p> -</div> - -<div class="notice"> -<p><span style="color: red"><b>WARNING:</b></span>This change may cause checksum -errors with misconfigured httpd servers. Since 1.7.14 and 1.8.5 the filename -in the request record now includes the filename in the repository, there have -been cases of mod_mime interfering with Subversion. Users will see a -<tt>svn: E200014: Checksum mismatch</tt> error when working with files that -end in .gz if a configuration setting like <tt>AddEncoding x-gzip .gz</tt> is -in their configuration file and applies to the locations that Subversion is -being served from. This happens because the setting now matches on the -Subversion traffic and sets the Content-Encoding header to specify that the -file has been gziped for transport without changing the file content. Since -the Subversion client supports gzip content-encoding it decompresses the file -and ends up with the decompressed file which does not match the checksum of the -file it expected. It is possible that this change may cause other filters to -match Subversion requests that would not have in the past and trigger other -similar errors with other httpd configurations.</p> -</div> - -</div> <!-- mod_dav_svn-fsmap --> - -<div class="h3" id="shattered-sha1"> -<h3>Subversion is unable to store SHA1 collisions - <a class="sectionlink" href="#shattered-sha1" - title="Link to this section">¶</a> -</h3> - -<p> -Subversion up to and including 1.8.17 can incorrectly store files with -different content but the same SHA1 checksum. We recommend that all -servers update to 1.8.18 and enable representation sharing. -See our <a href="/security/sha1-advisory.txt">SHA1 advisory</a> for details. -</p> - -</div> <!-- shattered-sha1 --> - -</div> <!-- issues --> - -<div class="h2" id="svn-1.6-deprecation"> -<h2>Subversion 1.6.x series no longer supported - <a class="sectionlink" href="#svn-1.6-deprecation" - title="Link to this section">¶</a> -</h2> - -<p>The Subversion 1.6.x line is no longer supported. This doesn't -mean that your 1.6 installation is doomed; if it works well and is all -you need, that's fine. "No longer supported" just means we've stopped -accepting bug reports against 1.6.x versions, and will not make any -more 1.6.x bugfix releases.</p> - -</div> <!-- svn-1.6-deprecation --> - -<!-- ***************** END CONTENT ****************** --> -</div> <!-- #site-content --> -</body> -</html> |