Subversion 1.6 Release Notes

What's New in Subversion 1.6

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 (

This page describes only major changes. For a complete list of changes, see the 1.6 section of the CHANGES file.

Compatibility Concerns

Older clients and servers interoperate transparently with 1.6 servers and clients. However, some of the new 1.6 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.

There is no need 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.

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.

New Feature Compatibility Table

New Feature Minimum Client1 Minimum Server Minimum Repository Notes
FSFS Packing any 1.6 1.6
Tree Conflicts 1.6 1.6 any Using servers older than 1.6 is possible, but some kinds of conflicts will not be detected.
1Reminder: when using the file:// repository access method, the Subversion program is both the client and the server.

Working Copy and Repository Filesystem Format Changes

The working copy format has been upgraded. This means that 1.5 and older Subversion clients will not be able to work with working copies produced by Subversion 1.6. Working copies are upgraded automatically.

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. svnserve, mod_dav_svn, svnadmin) won't be able to read a repository created by Subversion 1.6. But, repositories are not upgraded automatically.

Working Copy Upgrades

WARNING: if a Subversion 1.6 client encounters a pre-1.6 working copy, it will automatically 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 not occur with the repositories, only working copies.)

If you accidentally upgrade a 1.5 working copy to 1.6, and wish to downgrade back to 1.5, use the script. See this FAQ entry for details, and run the script with the --help option for usage instructions.

Repository Upgrades

The Subversion 1.6 server works with 1.5 and older repositories, and it will not upgrade such repositories to 1.6 unless specifically requested to via the svnadmin upgrade 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.)

Command Line Output Changes

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.

Improved output of svn proplist --verbose

The output of svn proplist --verbose has been improved, and svn propget now accepts the --verbose option. The following example illustrates these changes.

   $ svn proplist --verbose build.conf
   Properties on 'build.conf':

Changed output of svn status

The output of svn status 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.

   $ svn status
   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

Conflict summary printed by svn update and svn merge

svn update and svn merge now print a summary of conflicts upon completion.
$ svn update --accept=postpone
   C alpha
 C   beta
C    gamma
Updated to revision 3.
Summary of conflicts:
  Text conflicts: 1
  Property conflicts: 1
  Tree conflicts: 1
Minor problems with the conflict summary are described in issue 3342.

Hook Changes

Changed handling of output of pre-lock hook

The output of pre-lock hook was previously discarded, but now it is used to specify the names of lock tokens.

New Features

Repository root relative URLs (client)

This section is currently incomplete, please help write it! See the design notes for more information.

   $ svn SUBCOMMAND ^/

Improvements to svn:externals

Subversion 1.6 adds a couple of new features for users of svn:externals. The include:

Support for files in svn:externals (client)

If the URL in a svn:externals description refers to a file, it will be added into the working copy as a versioned item.

There are a few differences between directory and file externals.

  • 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.
  • 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.
  • 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.

The differences between a normal versioned file and a file external.

  • File externals cannot be moved or deleted; the svn:externals property must be modified instead; however, file externals can be copied.

Other facts.

  • A file external shows up as a X in the switched status column.

Support usual shell quoting rules in externals definitions (issue 2461, client)

Need to document possible incompatibilities (see this thread)

Further reading

See The svn:externals section of the Subversion Book.

Detection of tree conflicts (client)

Subversion 1.6 recognizes a new kind of conflict, known as a "tree conflict". Such conflicts manifest at the level of directory structure, rather than file content.

Situations now flagged as conflicts include deletions of locally modified files, and incoming edits to locally deleted files. Files and directories which are victims of a tree conflict cannot be committed before the conflict is marked resolved.

Note that Subversion is still treating renames as a "copy+delete" operation, so file renames causing tree conflicts can only be detected in terms of file additions and deletions. Because of this, false positives during tree conflict detection are possible.

To facilitate tree conflict detection, attempting to commit the deletion of a file which has already been deleted in the HEAD revision now causes an error. In Subversion 1.5, this was treated as a no-op, potentially resulting in "empty" revisions which contained no changes.

Further reading

See the tree conflicts section of the Subversion Book.

Filesystem Storage Improvements

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:

Sharing multiple common representations (issue 2286, server)

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.

FSFS repositories: Packing completed shards (server)

Subversion 1.5 introduced the ability for FSFS repositories to be sharded into multiple directories for revision and revprop files. Subversion 1.6 takes the sharding concept further, and allows full shard directories to be packed 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.

To pack a repository, run svnadmin pack 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.

FSFS repositories: Support for Memcached (server)

Memcached can cache data of FSFS repositories.

Additional build-time dependencies: APR-Util ≥1.3 || ( APR-Util < 1.3 && APR_Memcache )

BDB repositories: Forward deltas (server)

Newly created BDB repositories now use forward deltas instead of reverse deltas. svnadmin upgrade can be used to make older repositories use forward deltas for new revisions. If you want to achieve the most optimized state of an older repository, you still need to perform dump and load of the repository.

Ctypes Python Bindings

Subversion 1.6 introduces a new python binding for the Subversion API. The new binding makes use of the ctypes library to present the standard API along with a selection of Python classes to give an object-oriented interface to standard Subversion constructs. These bindings have several advantages over the traditional SWIG-based bindings:

  • Generated automatically
  • Straightforward, and don't have any special "transformation" rules
  • Pure python and cross-platform
  • Both forward and backward compatible as long as the functions used in the programs have compatible definitions
  • High level classes make it easy to access common subversion functionality in a pythonic way

Building the ctypes bindings produces two ways to access Subversion from python. The first interface is a direct python port of the standard API. Ctypes provides some basic type conversions and allows the calling of Subversion functions just like in C code. The new bindings also introduce a set of python classes to enable higher-level access to Subversion features. These classes take full advantage of python features and hide as much of the C implementation as possible to make Subversion easier to use for python programmers not familiar with the C API.

Enhancements and Bugfixes

Improved interactive conflict resolution (client)

Interactive conflict resolution supports new display-conflict, mine-conflict and theirs-conflict options.

Here's an example using the command-line client:

   $ svn up
   Conflict discovered in ''.
   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
   Updated to revision 36666.

Sparse directory exclusion

In Subversion 1.6, the --set-depth parameter to svn update has grown a new value—exclude. This value tells Subversion to exclude the target from the working copy, immediately and until further notice. Prior to Subversion 1.6, if a directory could not easily be removed from a working copy. If it was deleted without the help of Subversion, it would return on the next svn update. If it was deleted with svn delete, the directory remained as a local modification forever. (Unless, of course, it was accidentally committed.) The new exclusion mechanism in Subversion 1.6 fixes both these problems.

Note that if you exclude a versioned directory that has some unversioned files in it, or some files with local modifications, Subversion handles this situation gracefully. All the files that aren't safe to delete, Subversion leaves around, and of course leaves any intermediate directories required to reach those files, too.

Further reading

See this blog post for more examples and information.

Logging support for svnserve (server)

svnserve now accepts the --log-file option which allows to specify the file used for logging.

New public 'historical' HTTP URI syntax for mod_dav_svn (server)

mod_dav_svn now supports a new public URI syntax for examining older versions of files or directories. The intent here is to allow users to examine history without the use of an svn client, and to make it easier for 3rd-party tools (e.g. code-review services) to work directly against repositories without using svn libraries.


The new syntax works similarly to the way URIs work with the svn commandline client. Simply requesting http://host/repos/path fetches "path" in the HEAD revision. Adding a "p" query argument specifies a different peg revision instead, so that:

http://host/repos/path?p=38 similar to specifying "path@38" on the commandline. Adding a "r" query argument is like specifying "-r" on the commandline, causing the repository to follow history backwards from the peg revision to the older operative revision:


As with the commandline, the peg revision defaults to HEAD if unspecified, and the operative revision defaults to the peg revision. The online Subversion Book has a section explaining peg and operative revisions in great detail.

Command-line client improvements (client)

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 CHANGES file for a complete list.

log can take multiple revisions

The svn log command can now take multiple revision arguments in one invocation. Both the -c and -r arguments are supported.

   $ svn log -r36169 -r36171
   r36169 | sussman | 2009-02-26 14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line

   ...log message omitted...
   r36171 | joeswatosh | 2009-02-26 22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines

   ...log message omitted...
   $ svn log -c36169,36171
   r36169 | sussman | 2009-02-26 14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line

   ...log message omitted...
   r36171 | joeswatosh | 2009-02-26 22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines

   ...log message omitted...

--trust-server-cert option

Option added to svn and svnsync, so that non-interactive operations can work with self-signed certificates not backed by a known trust authority.

with this option:
   $ svn log -r36364 --trust-server-cert --non-interactive
   r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines
   ...log message omitted...
without this option:
   $ svn log -r36364 
   Error validating server certificate for '':
    - The certificate is not issued by a trusted authority. Use the
      fingerprint to validate the certificate manually!
   Certificate information:
    - Hostname:
    - Valid: from Sep 24 22:01:07 2007 GMT until Sep 23 22:01:07 2011 GMT
    - Issuer: sv, CollabNet, Brisbane, California, US
    - Fingerprint:
   (R)eject, accept (t)emporarily or accept (p)ermanently? t
   r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines

   ...log message omitted...

API changes, improvements and language bindings (client and server)

The pre-lock hook can now specify the lock-token string via the hook's stdout; see r32778 for details. Note that when the hook uses this feature, it must take responsibility for ensuring that lock tokens are unique across the repository.

There are too many new and revised APIs in Subversion 1.6.0 to list them all here. See the Subversion API Documentation 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.

One general change is that most APIs that formerly took a recurse parameter have been upgraded to accept a depth parameter instead, to enable the new sparse checkouts feature.

Language bindings have mostly been updated for the new APIs, though some may lag more than others.

Bug fixes (client and server)

A great many bugs have been fixed. See the 1.6.0 section in the CHANGES file for details.

Subversion 1.4.x series no longer supported

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.

New Dependency: SQLite

We now require SQLite to build both the server and client. We recommend 3.6.13 or greater, but work with anything better than 3.4.0. Subversion will attempt to use an SQLite amalgamation 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 --with-sqlite to configure to specify the location of the SQLite library or amalgamation you wish to use.