Apache Software Foundation
[S] Subversion

Apache Subversion 1.10 Release Notes

This is work in progress. Subversion 1.10 has not been released yet.

What's New in Apache Subversion 1.10

Apache Subversion 1.10 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.9.x is also in 1.10, but 1.10 contains features and bugfixes not present in any earlier release. The new features will eventually be documented in a 1.10 version of the free Subversion book (svnbook.red-bean.com).

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

Compatibility Concerns

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

Please note that svnadmin create will by default create repositories using the new filesystem format 8. Until Subversion 1.10 is generally available, no upgrade path is promised for repositories with this new filesystem format. Please do not use newly created repositories for any data meant for long-term safe-keeping. See our policy for pre-releases for additional information.

Subversion 1.10 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.10 libraries. However, a program written for 1.10 cannot necessarily compile or run against older libraries.

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 API errata for more detailed information on what these APIs are and what impact these changes may have.

New Feature Compatibility Table

New Feature Minimum Client1 Minimum Server Minimum Repository Notes
Improved path-based authorization any 1.10 any Existing authz configurations may need to be adjusted.
New interactive conflict resolver 1.10 any any Use SVN 1.8 and above clients only for best results.
LZ4 compression over the wire in http:// connections 1.10 1.10 any
LZ4 compression in the backend storage any any 1.10 FSFS only
1Reminder: when using the file:// repository access method, the Subversion program is both the client and the server.

Upgrading the Working Copy

Subversion 1.10 uses the same working copy format as Subversion 1.8 and 1.9.

Before using Subversion 1.10 with an existing Subversion 1.7 or older working copy, users will be required to run the svn upgrade command to upgrade working copy metadata to the new format. This command may take a while in some cases, and for some users, it may be more practical to simply checkout a new working copy.

Note: Subversion 1.10 cannot upgrade working copies that a 1.6 client would have refused to operate upon before an svn cleanup was run (with a 1.6 client). In other words, before upgrading to 1.8 or newer, a 1.6 or older client must be used to run svn cleanup on all 1.6 or older working copies that require cleanup. Likewise, Subversion 1.10 cannot upgrade corrupt working copies. Unfixable problems can arise from missing or corrupt meta-data inside .svn directories. Such damage to the working copy is permanent, and cannot be fixed even if svn cleanup is run prior to the upgrade.

If your working copy does not upgrade cleanly, please check out a new one.

Miscellaneous Compatibility Notes

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.

This release is numbered 1.10

Since "1.10.0" is smaller than "1.9.0" when considered as ASCII strings, scripts that compare Subversion versions as strings may fail to correctly determine which of "1.10.0" and "1.9.0" is the more recent one. Such scripts should be changed to compare Subversion version numbers correctly: as tuples of integers, with an optional suffix for development or pre-release versions. See the Subversion release numbering documentation for details. (Programs written against the C API or the various bindings should refer to the svn_version_* interfaces.)

svnadmin subcommands print locked paths differently

The svnadmin lock, svnadmin unlock, and svnadmin rmlocks subcommands print the locked path differently.

In 1.9 and earlier, the path would be printed out in exactly the form it was input. In 1.10, the path is printed in "canonical" form: with dot components (foo/./bar) elided and multiple slashes (foo//bar) compressed to one. The path also starts with a slash in the output, regardless of whether a leading slash was present in the input.


$ svnadmin-1.9 lock r //iota jrandom logmsg opaquelocktoken:42
'//iota' locked by user 'jrandom'.
$ svnadmin-1.9 unlock r //iota jrandom opaquelocktoken:42
'//iota' unlocked by user 'jrandom'.

$ svnadmin-1.10 lock r //iota jrandom logmsg opaquelocktoken:42
'/iota' locked by user 'jrandom'.
$ svnadmin-1.10 unlock r //iota jrandom opaquelocktoken:42
'/iota' unlocked by user 'jrandom'.

Only the output is changed. The set of valid inputs and the behaviour of svnadmin on them are unchanged. svnadmin continues to accept paths either with or without multiple slashes, dot components, and so on as command-line arguments.

svnserve honours use-sasl = true when built without SASL

The behaviour of svnserve when built without support for Cyrus SASL transport has changed.

In Subversion 1.9 and earlier, svnserve, when built without SASL support, would ignore the svnserve.conf use-sasl setting; In Subversion 1.10, svnserve, when built without SASL support, errors out if use-sasl is set to true.

svnserve's behaviour is otherwise unchanged. In particular, the behaviour of builds with SASL support is unchanged.

An API erratum is available.

New Features

Improved path-based authorization

Subversion 1.10 provides a new implementation of path-based authorization with improved performance and wildcard support.

Existing authz rules come in two flavours, repository-specific and global:

In these rules, /path is always matched literally.

The new authz rule parser supports two new forms for rules which may contain wildcards in the path element:


The following wildcard syntax elements are supported in glob rules:

  • * matches a single (exactly one), arbitrary path segment
  • ** matches an arbitrary number of path segments, separated by a forward slash: /
  • Classic wildcard patterns such as *foo*.bar work as expected, including escaping of special characters with a backslash: \

All wildcards apply to full path segments only, i.e. * never matches /, except for the case where /**/ matches zero or more path segments. For example, /*/**/* will match any path which contains at least 2 segments and is equivalent to /**/*/* as well as /*/*/**.

Because a glob rule is not required to contain wildcards in the path, two sections with different names may apply to the same path. For example, the following two rules are identical:

The new authz rule parser detects and rejects such collisions.

The old authz parser, in Subversion 1.9 and earlier, allowed syntactic entries which grant write-only access. For example:

   * = w
The new parser flags such entries as invalid. Neither the old nor the new authz implementation support write-only access.

New interactive conflict resolver

Subversion 1.10 provides much better interactive resolution of tree conflicts than previous releases. Interactive conflict resolution has been completely redesigned and rewritten. This new conflict resolver supersedes the first implementation introduced in Subversion 1.5.

The new conflict resolver searches repository history for structural changes (additions, deletions, copies, and moves) which conflict with local changes in the working copy and cause tree conflicts. Tree conflicts are now described in detail, including revision numbers and names of authors of conflicting changes. In previous versions of Subversion, the task of finding such information was left to the user. Automating this task is a huge usability improvement.

The new conflict resolver is able to detect moves and renames in repository history, and take them into account while modifying the local working copy. This makes seamless merging between branches possible even if one or both branches rename files or directories. For best results, all SVN clients committing to the repository should be at version 1.8 or higher.

The new conflict resolver will avoid asking users about resolution options whenever there is a only one reasonable course of action. For example, if a file was moved to another location in the repository, the conflict resolver will attempt to resolve the tree conflict on behalf of the user by performing the same move locally if necessary. This allows users to focus their attention on conflicts which cannot be resolved automatically.

Because detection of moves and renames involves heuristics, detection is not perfect and won't work in all conceivable cases. For a detailed description of how incoming moves and renames are detected, see How Subversion's conflict resolver handles incoming moves.

The conflict resolver user interface remains largely unchanged. Like in previous releases, the resolver will be started automatically if an update, merge, or switch operation ends with unresolved conflicts. It can also be started on demand by running the svn resolve command. For more information, run svn help resolve after installing Subversion 1.10.

In some situations, resolving one tree conflict will cause new other tree conflicts to appear. The svn resolve command will keep iterating over such conflicts until none are left, or until the user decides to quit the operation.

The new conflict resolver can be driven interactively with svn resolve, from Subversion's client API (in C and other language bindings), or with the non-interactive svnconflict tool which is intended for use in shell scripts.

The new conflict resolver offers a variety of automated tree conflict resolution options which users can choose from. Not all kinds of tree conflicts can yet be described and resolved. The options available in Subversion 1.10.0 are listed in the table below. In this table, the items on the incoming and local side are either both files or both directories. Most cases where files clash with directories are not handled yet.

Future releases of Subversion will continue to provide enhancements for the new conflict resolver. We expect to add coverage of additional conflict cases and add additional resolution options even in patch releases (i.e. in 1.10.1, 1.10.2, etc.).

local change incoming change operation resolution options
  • edit file
  • any change inside a directory
  • delete file / directory
update, switch, merge
  • ignore deletion
  • accept deletion
  • move file / directory
update, switch, merge
  • move and merge
    (applies the same move locally and merges items)
  • add item
  • add item
update, switch
  • ignore incoming addition
    (discards the incoming change)
  • merge incoming and local item
  • ignore incoming addition
    (discards the incoming change)
  • merge incoming and local item
    (item's log history will trace back on local branch)
  • replace local item with incoming item, then merge them
    (item's log history will trace back to other branch)
  • move item
  • edit file
  • any change inside directory
update, switch
  • apply change to move destination
  • break move and update any moved away children
    (updates items moved outside of the moved directory)
  • apply change to move destination
  • delete item
  • edit file
  • any change inside directory
update, switch, merge
  • keep working copy state (deleted file / directory),
    discarding incoming changes

LZ4 compression

Subversion 1.10 adds support for LZ4 compression as an alternative to the zlib compression that has been used in the previous versions. LZ4 offers fast compression and decompression while still maintaining a decent compression ratio. Using LZ4 compression can significantly improve performance of most of the Subversion operations for repositories with large and, possibly, incompressible files.

Currently, LZ4 compression can be enabled for the data transferred over http(s):// to Subversion 1.10 clients by setting the SVNCompressionLevel 1 directive in mod_dav_svn. Apart from this, it can also be enabled for the on-disk data in new repositories with filesystem format 8 (see below) by setting compression-level = 1 in the fsfs.conf configuration file.

Filesystem format bump

The default filesystem format is now a new format, numbered 8. (The svnadmin info command displays the filesystem format number of a repository.)

The format bump is required to allow using LZ4 compression for the on-disk data. In order to use LZ4 compression for existing data, it's required to perform a full dump/load cycle into a new repository with configured compression-level = 1 in the fsfs.conf configuration file.

WARNING: Until Subversion 1.10 is generally available, no upgrade path is promised for repositories with the filesystem format 8. Please do not upgrade your existing repositories used in production, and do not use newly created repositories for any data meant for long-term safe-keeping. See our policy for pre-releases for additional information.

Enhancements and Bugfixes

Command-line client improvements (client)

svnbench improvements

svnbench now displays its wall-clock run time and the total number of bytes transferred across the network. The --with-no-revprops option which did not actually work in Subversion 1.9 haas been fixed.

Server-side improvements

New --no-flush-to-disk option for svnadmin load

A new --no-flush-to-disk option has been added to the svnadmin load command. This option can be used to dramatically speed up the load process when there is no need to ensure that the resulting data survives a system crash or power loss, e.g. when loading a dump file into a fresh repository.

New svnadmin dump-revprops and svnadmin load-revprops subcommands

svnadmin can now dump and load revision properties independently of other changes made to the repository. This is useful because revision properties are not versioned but their values may change if the administrator has configured the repository's pre-revprop-change hook.

svnadmin dump-revprops will save the current values of all revision properties to a dump file. svnadmin load-revprops can be used to set revision properties in a repository to the values saved in a dump file.

Client-server improvements

RA-serf now compresses deltas when possible

RA-serf now sends deltas compressed when possible, unless compression is disabled by the 'http-compression = no' client configuration option. This is enabled for servers that advertise support for this specific (new) capability.

mod_dav_svn servers now advertise this specific (new) capability.

Ref. r1704317, r1704891, r1791290.

Known issues in the release

There are some known issues in the Subversion 1.10 releases. These may be fixed in later 1.10.x releases.

Troubleshooting issues specific to this release

Subversion 1.10 introduces new features and makes use of new techniques which can trigger problems not encountered in previous versions. In contrast to known issues, things listed here are not due to some bug or issue in Subversion itself and therefore cannot be fixed with a new patch release. This section lists all known problems and provides instructions to solve them, if they occur.

There are no known issues specific to this release at the moment.

Subversion 1.8.x series no longer supported

The Subversion 1.8.x line is no longer supported. This doesn't mean that your 1.8 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.8.x versions, and will not make any more 1.8.x bugfix releases.