svn_1.6_releasenotes.html [plain text]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style type="text/css"> /* <![CDATA[ */
@import "branding/css/tigris.css";
@import "branding/css/inst.css";
/* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
href="branding/css/print.css"/>
<script type="text/javascript" src="branding/scripts/tigris.js"></script>
<title>Subversion 1.6 Release Notes</title>
</head>
<body>
<div class="app">
<div class="warningmessage">
<p><strong>Note:</strong> Subversion 1.6 is <em>not released yet</em>.
When it is released, this warning message will disappear, and the rest
of this page will become the release notes. Until then, this page
describes what is planned for the release.</p>
</div>
<h1 style="text-align: center">Subversion 1.6 Release Notes</h1>
<div class="h2" id="news" title="news">
<h2>What's New in Subversion 1.6</h2>
<ul>
<li><a href="#auth-related-improvements"
>Improved handling of authentication data</a></li>
<li><a href="#repository-root-relative-urls"
>Repository root relative URLs</a></li>
<li><a href="#file-externals"
>Support for files in <tt>svn:externals</tt></a></li>
<li><a href="#tree-conflicts"
>Improved handling of tree conflicts</a></li>
<li><a href="#filesystem-improvements"
>Filesystem storage improvements</a></li>
<li><a href="#ctypes-python-bindings"
>Ctypes Python Bindings</a></li>
<li><a href="#improved-interactive-conflict-resolution"
>Improved interactive conflict resolution</a></li>
<li><a href="#svnserve-logging"
>Logging support for svnserve</a></li>
<li><a href="#cmdline"
>Command-line client improvements</a></li>
<li><a href="#apis"
>API changes, improvements, and much language bindings work</a></li>
<li><a href="#bug-fixes"
>More than XXX new bug fixes, enhancements</a></li>
</ul>
<p>Subversion 1.6 is a superset of all previous Subversion releases,
and is considered the current "best" release. Any feature or bugfix
in 1.0.x through 1.5.x is also in 1.6, but 1.6 contains features and
bugfixes not present in any earlier release. The new features will
eventually be documented in a 1.6 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.6 section of the <a
href="http://svn.collab.net/repos/svn/trunk/CHANGES" >CHANGES</a>
file.</p>
</div> <!-- news -->
<div class="h2" id="compatibility" title="compatibility">
<h2>Compatibility Concerns</h2>
<p>Older clients and servers interoperate transparently with 1.6
servers and clients. However, some of the new 1.6 features (e.g., <a
href="#XXX" >XXX</a>) may not be available
unless both client and server are the latest version . There are also
cases (e.g., <a href="#XXX">XXX</a>) 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 dump and reload your
repositories. Subversion 1.6 can read repositories created by earlier
versions. To upgrade an existing installation, just install the
newest libraries and binaries on top of the older ones.</p>
<p>Subversion 1.6 maintains API/ABI compatibility with earlier
releases, by only adding new functions, never removing old ones. A
program written to the 1.0, 1.1, 1.2, 1.3, 1.4 or 1.5 API can both compile
and run using 1.6 libraries. However, a program written for 1.6
cannot necessarily compile or run against older libraries.</p>
<div class="h3" id="new-feature-compatibility-table"
title="new-feature-compatibility-table">
<h3>New Feature Compatibility Table</h3>
<table border="1">
<tr>
<th>New Feature</th>
<th>Minimum Client</th>
<th>Minimum Server</th>
<th>Minimum Repository</th>
<th>Notes</th></tr>
<tr>
<td><a href="#XXX">XXX</a></td>
<td>1.6</td>
<td>1.6</td>
<td>1.6</td>
<td></td></tr>
<tr>
<td><a href="#XXX">XXX</a></td>
<td>1.6</td>
<td>any</td>
<td>any</td>
<td></td></tr>
</table>
</div> <!-- new-feature-compatibility-table -->
<div class="h3" id="wc-and-fs-format-change"
title="wc-and-fs-format-change">
<h3>Working Copy and Repository Filesystem Format Changes</h3>
<p>The working copy format has been upgraded. This means that 1.5 and
older Subversion clients will <em>not</em> be able to work with
working copies produced by Subversion 1.6. Working copies are <a
href="#wc-upgrades" >upgraded automatically</a>.</p>
<p>Similarly, the repository filesystem formats have changed, meaning
that 1.5 and older versions of Subversion tools that normally access
a repository directly (e.g. <tt>svnserve</tt>, <tt>mod_dav_svn</tt>,
<tt>svnadmin</tt>) won't be able to read a repository created by
Subversion 1.6. But, repositories are <a href="#repos-upgrades"
><strong>not</strong> upgraded automatically</a>.</p>
<div class="h4" id="wc-upgrades" title="wc-upgrades">
<h4>Working Copy Upgrades</h4>
<p><strong>WARNING:</strong> if a Subversion 1.6 client encounters a
pre-1.6 working copy, it will <em>automatically</em> upgrade the
working copy format as soon as it touches it, making it unreadable by
older Subversion clients. If you are using several versions of
Subversion on your machine, be careful about which version you use in
which working copy, to avoid accidentally upgrading a working copy.
(But note that this "auto upgrade" behavior does <em>not</em> occur
with the <a href="#repos-upgrades" >repositories</a>, only working
copies.)</p>
<p>If you accidentally upgrade a 1.5 working copy to 1.6, and wish to
downgrade back to 1.5, use the <a
href="http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py"
><tt>change-svn-wc-format.py</tt></a> script. See <a
href="http://subversion.tigris.org/faq.html#working-copy-format-change"
>this FAQ entry</a> for details, and run the script with the
<code>--help</code> option for usage instructions.</p>
</div> <!-- wc-upgrades -->
<div class="h4" id="repos-upgrades" title="repos-upgrades">
<h4>Repository Upgrades</h4>
<p>The Subversion 1.6 server works with 1.5 and older repositories,
and it will <em>not</em> upgrade such repositories to 1.6 unless
specifically requested to via the
<strong><code>svnadmin upgrade</code></strong> command. This means
that some of the new 1.6 features will not become available simply by
upgrading your server: you will also have to upgrade your
repositories. (We decided not to auto-upgrade repositories because we
didn't want 1.6 to silently make repositories unusable by
1.5 — that step should be a conscious decision on the
part of the repository admin.)</p>
</div> <!-- repos-upgrades -->
</div> <!-- wc-and-fs-format-change -->
<div class="h3" id="output-changes" title="output-changes">
<h3>Command Line Output Changes</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.</p>
<div class="h4" id="proplist-verbose" title="proplist-verbose">
<h4>Improved output of <code>svn proplist --verbose</code></h4>
<p>XXX(r32484): The output of <code>svn proplist --verbose</code> has been
improved.</p>
<pre>
$ svn proplist --verbose build.conf
Properties on 'build.conf':
svn:eol-style
native
svn:mergeinfo
/trunk/build.conf:1-4800
/branches/a/build.conf:3000-3400
/branches/b/build.conf:3200-3600
$
</pre>
</div> <!-- proplist-verbose -->
<div class="h4" id="svn-status" title="svn-status">
<h4>Changed output of <code>svn status</code></h4>
<p>The output of <code>svn status</code> contains the additional seventh
column which informs whether the item is the victim of a tree conflict.
An additional line with more detailed description of a tree conflict is
displayed after each item remaining in tree conflict.</p>
<pre>
$ svn status
M Makefile.in
A C src/error.c
> local add, incoming add upon update
M src/log.c
M C src/path.c
> local edit, incoming delete upon update
D C src/properties.c
> local delete, incoming edit upon merge
M C src/time.c
$
</pre>
</div> <!-- svn-status -->
</div> <!-- output-changes -->
<div class="h3" id="hook-changes" title="hook-changes">
<h3>Hook Changes</h3>
<div class="h4" id="pre-lock-hook-output" title="pre-lock-hook-output">
<h4>Changed handling of output of <code>pre-lock</code> hook</h4>
<p>XXX(r32778)</p>
</div> <!-- pre-lock-hook-output -->
</div> <!-- hook-changes -->
</div> <!-- compatibility -->
<div class="h2" id="new-features" title="new-features">
<h2>New Features</h2>
<div class="h3" id="auth-related-improvements" title="auth-related-improvements">
<h3>Improved handling of authentication data (<em>client</em>)</h3>
<p>XXX</p>
<div class="h4" id="auth-related-improvements-plaintext-passwords"
title="auth-related-improvements-plaintext-passwords">
<h4>Prompting before storing passwords in plaintext form</h4>
<p>Subversion prompts before storing passwords in plaintext form.</p>
<p>Example:</p>
<pre>
$ svn checkout https://www.example.com/repository/trunk repository_trunk
Authentication realm: <https://www.example.com> Example
Password for 'user':
-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:
<https://www.example.com> Example
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/user/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)?
</pre>
</div> <!-- auth-related-improvements-plaintext-passwords -->
<div class="h4" id="auth-related-improvements-kwallet-gnome-keyring"
title="auth-related-improvements-kwallet-gnome-keyring">
<h4>Support for storing passwords in KWallet and GNOME Keyring (Unix-like systems)</h4>
<p>Passwords can be stored in KWallet (KDE 4) and GNOME Keyring.</p>
</div> <!-- auth-related-improvements-kwallet-gnome-keyring -->
<div class="h4" id="auth-related-improvements-ssl-client-certificate-passphrases"
title="auth-related-improvements-ssl-client-certificate-passphrases">
<h4>Support for storing SSL client certificate passphrases</h4>
<p>SSL client certificate passphrases can be stored in KWallet, GNOME
Keyring, Mac OS Keychain, a Windows CryptoAPI encrypted form or in plaintext form.</p>
</div> <!-- auth-related-improvements-ssl-client-certificate-passphrases -->
</div> <!-- auth-related-improvements -->
<div class="h3" id="repository-root-relative-urls"
title="repository-root-relative-urls">
<h3>Repository root relative URLs (<em>client</em>)</h3>
<p>XXX (<a href="http://svn.collab.net/repos/svn/trunk/notes/cli-repo-root-relative-support.txt">Description</a>)</p>
<pre>
$ svn SUBCOMMAND ^/
$ svn SUBCOMMAND ^/PATH
</pre>
</div> <!-- repository-root-relative-urls -->
<div class="h3" id="file-externals" title="file-externals">
<h3>Support for files in <tt>svn:externals</tt>
(<em>client</em>)</h3>
<p>
If the URL in a <tt>svn:externals</tt> description refers to a file,
it will be added into the working copy as a versioned item.
</p>
<p>
There are a few differences between directory and file
externals.
</p>
<ul>
<li>
The path to the file external must be in a working copy that is
already checked out. While directory externals can place the
external directory at any depth and it will create any
intermediate directories, file externals must be placed into a
working copy that is already checked out.
</li>
<li>
The file external's URL must be in the same repository as the URL
that the file external will be inserted into; inter-repository
file externals are not supported.
</li>
<li>
While commits do not descend into a directory external, a commit
in a directory containing a file external will commit any
modifications to the file external.
</li>
</ul>
<p>The differences between a normal versioned file and a file
external.</p>
<ul>
<li>
File externals cannot be moved or deleted; the
<tt>svn:externals</tt> property must be modified instead; however,
file externals can be copied.
</li>
</ul>
<p>Other facts.</p>
<ul>
<li>
A file external shows up as a <tt>X</tt> in the switched status
column.
</li>
</ul>
<div class="h4" id="file-externals-further-reading"
title="file-externals-further-reading">
<h4>Further reading</h4>
<p>See The <a
href="http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html"
>svn:externals</a> section of the Subversion Book.</p>
</div> <!-- file-externals-further-reading -->
</div> <!-- file-externals -->
<div class="h3" id="tree-conflicts" title="tree-conflicts">
<h3>Improved handling of tree conflicts (<em>client</em>)</h3>
<p>Improved handling of tree conflicts.</p>
</div> <!-- tree-conflicts -->
<div class="h3" id="filesystem-improvements" title="filesystem-improvements">
<h3>Filesystem Storage Improvements</h3>
<p>Subversion 1.6 contains several improvements to both the Berkeley DB and FSFS
backends. These are designed to improve storage space, and can result in
drastically smaller repositories. These changes include:</p>
<ul>
<li><a href="#rep-sharing"
>Representation sharing</a></li>
<li><a href="#fsfs-packing"
>FSFS inode packing</a></li>
<li><a href="#fsfs-memcached"
>FSFS repositories: Support for Memcached</a></li>
<li><a href="#bdb-reverse-deltas"
>BDB repositories: Reverse deltas</a></li>
</ul>
<div class="h4" id="rep-sharing" title="rep-sharing">
<h4>Sharing multiple common representations
(<em><a href="/issues/show_bug.cgi?id=2286">issue 2286</a></em>,
<em>server</em>)</h4>
<p>XXX:When using many branches and merging between them often, it is common to
have files with similar lines of history which contain the exact same content.
In the past, Subversion has stored these files as deltas against previous
versions of the file. Subversion 1.6 will now use existing representations in
the filesystem for duplicate storage. Depending on the size of the repository,
and the degree of branching and merging, this can cause an up to 20% space
reduction for Berkeley DB repositories and a 15% reduction for FSFS
repositories.</p>
</div> <!-- rep-sharing -->
<div class="h4" id="fsfs-packing" title="fsfs-memcached">
<h4>FSFS repositories: Packing completed shards (<em>server</em>)</h4>
<p>Subversion 1.5 introduced the ability for FSFS repositories to be
<em><a href="svn_1.5_releasenotes.html#fsfs-sharding">sharded</a></em> into
multiple directories for revision and revprop files. Subversion 1.6 takes
the sharding concept further, and allows full shard directories to be
<em>packed</em> into a single file. By reducing internal fragmentation in
the filesystem, packed FSFS repositories have significant space savings
over their unpacked counterparts, especially repositories which contain
many small commits. Using a one-file-per-shard approach also allows
Subversion to reduce disk I/O and better exploit operating system caches.
</p>
<p>To pack a repository, run <code>svnadmin pack</code> on the repository.
Once a repository has been packed, there is no migration path back to an
unpacked state, and it can only be read by Subversion 1.6 or greater
servers.</p>
</div> <!-- fs-packing -->
<div class="h4" id="fsfs-memcached" title="fsfs-memcached">
<h4>FSFS repositories: Support for Memcached (<em>server</em>)</h4>
<p>XXX: <a href="http://www.danga.com/memcached/">Memcached</a> can cache
data of FSFS repositories.</p>
<p>Additional build-time dependencies: APR-Util ≥1.3 || ( APR-Util <
1.3 && APR_Memcache )</p>
</div> <!-- fsfs-memcached -->
<div class="h4" id="bdb-reverse-deltas" title="bdb-reverse-deltas">
<h4>BDB repositories: Reverse deltas (<em>server</em>)</h4>
<p>XXX</p>
</div> <!-- bdb-reverse-deltas -->
</div> <!-- filesystem-improvements -->
<div class="h3" id="ctypes-python-bindings" title="ctypes-python-bindings">
<h3>Ctypes Python Bindings</h3>
<p>XXX</p>
</div> <!-- ctypes-python-bindings -->
</div> <!-- new-features -->
<div class="h2" id="enhancements" title="enhancements">
<h2>Enhancements and Bugfixes</h2>
<div class="h3" id="improved-interactive-conflict-resolution"
title="improved-interactive-conflict-resolution">
<h3>Improved interactive conflict resolution (<em>client</em>)</h3>
<p>dc, mc, tc options.</p>
<p>Here's an example using the command-line client:</p>
<pre>
$ svn up
U Makefile.in
Conflict discovered in 'configure.ac'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: s
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: mc
G configure.ac
Updated to revision 36666.
$
</pre>
</div> <!-- improved-interactive-conflict-resolution -->
<div class="h3" id="svnserve-logging"
title="svnserve-logging">
<h3>Logging support for svnserve (<em>server</em>)</h3>
<p>XXX</p>
</div> <!-- svnserve-logging -->
<div class="h3" id="cmdline" title="cmdline">
<h3>Command-line client improvements (<em>client</em>)</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.6.0 section in the <a
href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
for a complete list.</p>
<div class="h4" id="trust-server-cert" title="trust-server-cert">
<h4>--trust-server-cert option</h4>
<p>XXX</p>
</div> <!-- trust-server-cert -->
</div> <!-- cmdline -->
<div class="h3" id="apis" title="apis">
<h3>API changes, improvements and language bindings
(<em>client and server</em>)</h3>
<p>The <tt>pre-lock</tt> hook can now specify the lock-token string
via the hook's stdout; see <a
href="http://svn.collab.net/viewcvs/svn?rev=32778&view=rev"
>r32778</a> for details. Note that when the hook uses this feature,
it must take responsibility for ensuring that lock tokens are unique
across the repository.</p>
<p>There are too many new and revised APIs in Subversion 1.6.0 to list
them all here. See the <a
href="http://svn.collab.net/svn-doxygen/" >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>One general change is that most APIs that formerly took a
<tt>recurse</tt> parameter have been upgraded to accept a
<tt>depth</tt> parameter instead, to enable the new <a
href="#sparse-checkouts">sparse checkouts</a> feature.</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" title="bug-fixes">
<h3>Bug fixes (<em>client and server</em>)</h3>
<p>A great many bugs have been fixed. See the 1.6.0 section in the <a
href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
for details.</p>
</div> <!-- bug-fixes -->
</div> <!-- enhancements -->
<div class="h2" id="svn-1.4-deprecation" title="svn-1.4-deprecation">
<h2>Subversion 1.4.x series no longer supported</h2>
<p>The Subversion 1.4.x line is no longer supported. This doesn't
mean that your 1.4 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.4.x versions, and will not make any
more 1.4.x bugfix releases, except perhaps for absolutely critical
security or data-loss bugs.</p>
</div> <!-- svn-1.4-deprecation -->
<div class="h2" id="sqlite" title="sqlite">
<h2>New Dependency: SQLite</h2>
<p>XXX: We now require <a href="http://www.sqlite.org/">SQLite</a> for both
the server and client. We recommend 3.6.10 or greater, but work with
anything better than 3.4.0. Subversion will attempt to use an SQLite
<a href="http://www.sqlite.org/amalgamation.html">amalgamation</a> if it is
present in the root of the distribution tarball, otherwise, Subversion will
search for SQLite in the usual places on the system. You may also pass
<code>--with-sqlite</code> to <code>configure</code> to specify the location
of the SQLite library or amalgamation you wish to use.</p>
</div> <!-- sqlite -->
</div> <!-- app -->
</body>
</html>