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 (svnbook.red-bean.com).
This page describes only major changes. For a complete list of changes, see the 1.8 section of the CHANGES file.
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.
There is no need to dump and reload 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.
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.
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 |
|---|---|---|---|---|
| working copy records moves | 1.8 | any | any | |
| Automatic reintegration merge | 1.8 | 1.5 | 1.5 | |
| neon support removed | 1.8 | any | any | Server-side configuration changes might be required for optimal performance with 1.8 clients which access the repository via HTTP. |
| Inheritable properties | 1.8 | any | any | A 1.8 server isn't required but will deliver superior performance when asked for inherited properties. |
| Repos dictated config props | 1.8 | any | any | |
| Password caching with gpg-agent | 1.8 | any | any | |
| FSFS enhancements | any | 1.8 | 1.8 | Repository size reduction requires dump/load. |
| Authz file in repository | any | 1.8 | any | |
| 1Reminder: when using the file:// repository access method, the Subversion program is both the client and the server. | ||||
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.
Before using Subversion 1.8 with existing working copies, 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, and for some users, it may be more practical to simply checkout a new working copy.
Subversion 1.8 can only upgrade working copies created with Subversion 1.6 and Subversion 1.7.
Note: Subversion 1.8 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, a 1.6 client must be used to run svn cleanup 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 .svn directories. Such damage to the 1.6 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.
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 --xml option, or accessing Subversion through the various bindings interfaces.
The default output of svn mergeinfo has been changed. Instead of being equivalent to svn mergeinfo --show-revs=merged, it now shows a diagrammatic summary of some information about merges between the two specified branches:
$ 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
$
Scripts using svn mergeinfo without a --show-revs= option should be updated to add --show-revs=merged.
The default output for these commands remains the same, but both support the new option --show-inherited-props which may produce output changes from 1.7.x. See inheritable properties for more information.
The output of svnlook proplist and svnlook proplist --verbose has changed and now mimics the output of svn proplist and svn proplist --verbose respectively. svnlook propget now supports the --verbose option, which produces output similar to svn propget --verbose.
Both svnlook proplist and svnlook propget now support the new option --show-inherited-props which may produce output changes from 1.7.x. See inheritable properties for more information.
svn status now shows moves in its output. See the section about local moves for more information.
svn status shows an extra line for each item involved in a move:
$ svn move epsilon/zeta zeta-moved
$ svn status
D epsilon/zeta
> moved to zeta-moved
A + zeta-moved
> moved from epsilon/zeta
$
svn info shows extra lines for locally moved items, too. For example, if the file beta was moved to beta-new, svn info beta will show the following (some unrelated output has been omitted in this example):
$ svn info beta Path: beta [...] Schedule: delete Moved To: beta-new [...]
$ svn info README Path: README Name: README Working Copy Root Path: /tmp/svn-trunk URL: https://svn.apache.org/repos/asf/subversion/trunk/README Relative URL: ^/subversion/trunk/README 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
HTTP client support based on neon has been removed in favor of HTTP client support based on serf.
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.
Note that server-side configuration changes might be required to avoid performance regressions for serf clients in some setups.
The MaxKeepAliveRequests option in httpd.conf needs to be increased from 100 (the default) to at least 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.
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.
The main benefit of skelta mode is that it allows a correctly set up Apache server or intermediate proxy server to cache mod_dav_svn’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.
Skelta mode has some disadvantages:
This release introduces two options to control if the svn client will use skelta or bulk update mode.
Table explaining the mode used between each combination of svn client and server version and relevant configuration directives:
| 1.8 Server with SVNAllowBulkUpdates: |
1.7 and older Server with SVNAllowBulkUpdates: |
||||
|---|---|---|---|---|---|
| Subversion Client | Off | On* | Prefer | Off | On* |
| 1.8, http-bulk-updates: auto* | Skelta mode | Skelta mode | Bulk mode | Skelta mode | Bulk mode |
| 1.8, http-bulk-updates: yes | Skelta mode | Bulk mode | Bulk mode | Skelta mode | Bulk mode |
| 1.8, http-bulk-updates: no | Skelta mode | Skelta mode | Skelta mode | Skelta mode | Skelta mode |
| 1.7 and older with neon* | Skelta mode | Bulk mode | Bulk mode | Skelta mode | Bulk mode |
| 1.7 and older with serf | Skelta mode | Skelta mode | Skelta mode | Skelta mode | Skelta mode |
*Default configuration
The Subversion developers have decided to deprecate 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.
This being a volunteer project, we are of course always happy to accept contributions towards maintaining the Berkeley DB back-end.
The only visible effect of the deprecation is that the
svnadmin utility will print a warning when it
creates a new Berkeley DB-based repository.
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.
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 /trunk/secretdir) 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.
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 all access to items in your repositories being unexpectedly denied as a result of upgrading to Subversion 1.8. The svnauthz 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.)
When Apache is configured with the SVNParentPath
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.
NOTE: Access to "Collection of Repositories" is not 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 INSTALL document for additional details.
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 metadata was affected; file contents and properties was not.) As of 1.7.1 Subversion prevents new instances of the corruption, but only as of 1.8.0 does 'svnadmin verify' detect instances of that corruption in the history of a repository.
The fix to these issues is simple: perform a dump/load cycle. (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.
See this summary of issue #4129 for more information about these problems.
Subversion has long supported the use of SSL client certificates
for authentication against a server which accepts such. Users
typically employ the ssl-client-cert-file 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.
Prior to 1.8.0, this prompting was enabled by default.
Unfortunately, not every server which accepts client certificates
also requires 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 not prompting for the location
of an SSL client certificate file unless the user has set the new
ssl-client-cert-file-prompt runtime configuration
option (found in the [auth] section of the 'config' file)
to "yes".
See issue #2410 for discussion and details.
The swig-py bindings have been changed to make *-imports of submodules to do the right thing: from svn.client import * will now import only symbols beginning with svn_ or SVN_. (Most of these symbols will be svn_client_* symbols, of course.) Star-imports of from svn have not changed (they import just the bare submodule names: 'fs', 'ra', etc), and star imports of from svn.core currently imports some select symbols (notably 'Pool' and 'SubversionException').
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.
The behavior of the --config-file 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 --config-file was used.
The svnserve.conf file directly passed to --config-file 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 --config-file more consistent with configurations that do not use this option.
If you were depending on the configuration changes not being applied until you restarted svnserve you will need to adjust accordingly.
The svnauthz-validate command has been renamed to svnauthz and now has a 'validate' subcommand. Meaning the equivalent to svnauthz-validate file in 1.8 is svnauthz validate file. To maintain command line compatibility, if the svnauthz command is run with the command name of svnauthz-validate then it emulates the behavior of the svnauthz-validate command from 1.7. make install-tools installs a symlink svnauthz-validate to provide this compatibility functionality.
svnauthz also provides new functionality. See this section for details.
The effect of the svn move command is now different from running svn copy followed by svn delete. Moves are represented within the working copy as a copy and a delete which are linked to one another. These links are shown by svn status and svn info.
Some Subversion operations will now treat locally moved files and directories specially. Behavioural changes include:
svn move now refuses to move a mixed-revision working copy.
svn commit 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.
svn update, svn switch, and svn resolve 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.
Limitations:
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.
Known issues:
Tree conflicts involving replacements are currently not detected when updating a moved file or directory (see issue #4318).
Tree conflicts flagged by svn merge cannot be automatically resolved yet. This will be addressed in a future release.
During merges which merge all eligible revisions from another branch, Subversion 1.8 will automatically decide whether or not the merge is reintegrating a branch. Therefore, reintegrating a branch does no longer require the --reintegrate option for correct operation.
The --reintegrate option of svn merge 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:
$ svn merge ^/branches/my-branch
This merge will still perform similar sanity checks which svn merge --reintegrate performed in earlier releases:
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 --reintegrate merge, an automatic reintegration merge into a working copy with local modifications is allowed.
Merging to-and-fro between two branches in any order is possible using the automatic reintegration merge (the "keep-alive dance" is no longer necessary). For best results, it is recommended to always merge all eligible revisions, i.e. not using the -r or -c options of svn merge. Merging just a subset of eligible revisions increases the likelihood of problems during future merges.
Using --reintegrate in Subversion 1.8 will force a reintegration merge, whether or not that's the right merge to perform in the given situation.
Property inheritance provides a mechanism to find the versioned properties set on the parents 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.
It is important to note that this change does not 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.
Other than the changes detailed below, the only user visible changes resulting from inheritable properties are to the svn proplist, svn propget, svnlook proplist, and svnlook propget subcommands when used with the new --show-inherited-props option.
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:
> svn propget -vR --show-inherited-props tsvn:logwidthmarker ^/subversion/trunk/subversion/po
Inherited properties 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
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:
> svn propget -vR --show-inherited-props tsvn:logwidthmarker po-wc\de.po
Inherited properties on 'po-wc\de.po',
from 'https://svn.apache.org/repos/asf/subversion/trunk':
tsvn:logwidthmarker
78
Inherited properties on 'po-wc\de.po',
from 'po-wc':
tsvn:logwidthmarker
80
The output with the --xml option also returns inherited properties, wrapping them in inherited_property rather than property tags:
> 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">
<inherited_property
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>
The svnlook proplist and svnlook propget subcommands also support the new --show-inherited-props option. The output is similar to svn proplist --show-inherited-props and svn propget --show-inherited-props except that the paths are not working copy paths or URLs, but absolute repository paths:
> svnlook propget asf-repos-mirror tsvn:logwidthmarker /subversion/trunk/subversion/po \
--show-inherited-props -v
Inherited properties on '/subversion/trunk/subversion/po',
from '/subversion/trunk':
tsvn:logwidthmarker
78
Properties on '/subversion/trunk/subversion/po':
tsvn:logwidthmarker
80
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.
For the full details about inheritable properties see the design wiki. 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:
Two new Subversion reserved properties, svn:auto-props and svn:global-ignores make use of the new inherited properties feature to provide additional configuration information that overrides/extends some of the settings found in the user's runtime configuration. The svn:auto-props property overrides/extends the auto-props configuration setting. The svn:global-ignores property extends the global-ignores configuration setting as well as the svn:ignore property.
The format of svn:auto-props property values are the same as for the auto-props runtime configuration. The format of svn:global-ignores property values are the same as for the global-ignores runtime configuration.
Both properties work just like their analogs in the runtime configuration with two exceptions:
When multiple svn:global-ignores properties apply to a path, then the different values are appended to any runtime global-ignores in effect and the value of any svn:ignore property that applies to the path.
Patterns defined in svn:auto-props property override any identical patterns in the auto-props runtime config. When multiple svn:auto-props properties apply to a file, the pattern from the nearest inheritable property takes precedence. See this section of design wiki for a full explanation.
The design wiki 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.
Subversion 1.8 allows the use of the GnuPG Agent (gpg-agent) daemon to temporarily store Subversion passwords in memory.
This feature does not use PGP to encrypt passwords on disk! Rather, it caches passwords in memory (in plaintext) instead of saving them to disk.
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 GPG_AGENT_INFO and GPG_TTY environment variables set up correctly. See this page for more information about running the gpg-agent.
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 kill(1) utility.
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.
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 ~/.subversion/auth/svn.simple. Unlike with GNOME Keyring or KDE Wallet, the user is not prompted for permission if another program attempts to access the password.
WARNING: 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.
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.
The default repository format created by svnadmin create 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 revprop packing. To create FSFS repositories compatible with Subversion 1.6 and 1.7, use the --compatible-version 1.6 parameter.
You may use svnadmin upgrade to upgrade existing repositories. However, to fully benefit from the latest repository size reductions, it is recommended to create a new repository, adjust its settings and then dump/load or svnsync the contents into it.
Format 6 repositories 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 rev