This is work in progress. Subversion 1.10 has not been released yet.
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.
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.
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||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.|
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.
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.
The next minor release after 1.10.0 will be numbered 1.11.0.
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:
[repos:/path] [/path]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:
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:
[/path/without/wildcards] [:glob:/path/without/wildcards]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:
[/] * = wThe new parser flags such entries as invalid. Neither the old nor the new authz implementation support write-only access.
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|
||update, switch, merge||
||update, switch, merge||
||update, switch, merge||
svn log --search is now case-insensitive and ignores diacriticals when matching words. This makes it easier to match paths and log messages which happen to contain upper-case and non-English characters.
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.
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.
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.
RA-serf now sends deltas compressed (in 'svndiff1' format) when possible, unless compression is disabled by the 'http-compression = no' client configuration option. This is enabled for servers that advertise support for either this specific (new) capability or Subversion's HTTP v2 protocol.
mod_dav_svn servers now advertise this specific (new) capability.
There are some known issues in the Subversion 1.10 releases. These may be fixed in later 1.10.x releases.
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.
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.