diff options
| author | James McCoy <jamessan@debian.org> | 2014-01-01 01:30:06 +0000 |
|---|---|---|
| committer | James McCoy <jamessan@debian.org> | 2014-01-01 01:30:06 +0000 |
| commit | a216f7147571439c5c1aec50d80804daf91a28d7 (patch) | |
| tree | 70a8f5e1c544b1e44d4cd908071a78c54eea5853 /debian/svn_1.8_releasenotes.html | |
| parent | a62bb7dd22ac5cbe0c63d93f7a695a7856e1ddc4 (diff) | |
Add 1.8 release notes
Diffstat (limited to 'debian/svn_1.8_releasenotes.html')
| -rw-r--r-- | debian/svn_1.8_releasenotes.html | 2622 |
1 files changed, 2622 insertions, 0 deletions
diff --git a/debian/svn_1.8_releasenotes.html b/debian/svn_1.8_releasenotes.html new file mode 100644 index 0000000..f017529 --- /dev/null +++ b/debian/svn_1.8_releasenotes.html @@ -0,0 +1,2622 @@ +<!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" /> +<style type="text/css"> + @import url("/style/site.css"); +</style> +</head> + +<body> +<div id="site-nav"> + +<div id="copyright"> +<p>Copyright © 2011 <a href="http://www.apache.org/">The Apache + Software Foundation</a>, Licensed under + the <a href="http://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="http://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="http://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>Subversion 1.8 can only upgrade working copies created with Subversion 1.6 +and Subversion 1.7.</p> + +<p><strong>Note:</strong> Subversion 1.8 cannot upgrade working copies that +a 1.6 client would have refused to operate upon before an <tt>svn cleanup</tt> +was run (with a 1.6 client). In other words, before upgrading to 1.8, a 1.6 +client must be used to run <tt>svn cleanup</tt> on all 1.6 working copies that +require cleanup. Likewise, Subversion 1.8 cannot upgrade corrupt 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="http://subversion.apache.org/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="http://code.google.com/p/serf/">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="http://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 reponse.</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="http://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> +<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> + +<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 +either does not begin with a slash or contains two consecutive slashes. +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="http://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="http://subversion.tigris.org/issues/show_bug.cgi?id=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="http://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="http://subversion.tigris.org/issues/show_bug.cgi?id=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="http://wiki.apache.org/subversion/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="http://wiki.apache.org/subversion/InheritedProperties#Differentiating_.27Inheritable.27_Vs._.27Normal.27_Properties"> + Differentiating 'Inheritable' Vs. 'Normal' Properties</a> + </li> + <li> + <a href="http://wiki.apache.org/subversion/InheritedProperties#General_Inheritance_Rules"> + General Inheritance Rules</a> + </li> + <li> + <a href="http://wiki.apache.org/subversion/InheritedProperties#Repository_Inheritance_Rules"> + Repository Inheritance Rules</a> + </li> + <li> + <a href="http://wiki.apache.org/subversion/InheritedProperties#Working_Copy_Inheritance_Rules"> + Working Copy Inheritance Rules</a> + </li> + <li> + <a href="http://wiki.apache.org/subversion/InheritedProperties#Authentication"> + Authentication</a> + </li> + <li> + <a href="http://wiki.apache.org/subversion/InheritedProperties#Subcommand_Changes"> + 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="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Format" +>format</a> of <tt>svn:auto-props</tt> property values +are the same as for the <tt>auto-props</tt> runtime configuration. +The <a href="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Ignores_Format" +>format</a> of <tt>svn:global-ignores</tt> property values are the +same as for the <tt>global-ignores</tt> runtime configuration.</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="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Hierarchy_and_Precedence" +>this section of design wiki</a> for a full explanation.</p> + +<p>The <a href="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Hierarchy_and_Precedence" +>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="http://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> <!-- 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="http://subversion.apache.org/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="http://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="http://subversion.tigris.org/issues/show_bug.cgi?id=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="http://subversion.tigris.org/issues/show_bug.cgi?id=4081" +>issue 4081</a> for more information.</p> + +<div class="notice"> +<p>Using general-purpose incremental backup tools, such as +<a href="http://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="http://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="http://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="http://subversion.apache.org/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="http://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="http://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="http://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="#hooks-post-commit" + title="Link to this section">¶</a> +</h4> + +<p>As documented in <a +href="http://subversion.tigris.org/issues/show_bug.cgi?id=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="http://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="http://people.apache.org/~pquerna/" +rel="nofollow">Paul Querna</a> for the <a href="http://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="http://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/#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="http://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>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>svn:/var/svn/repo/trunk/myfile</tt>. Note that the 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> <!-- mod_dav_svn-fsmap --> + +</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> |