Apache Subversion 1.9 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.8.x is also in 1.9, but 1.9 contains features and bugfixes not present in any earlier release. The new features will eventually be documented in a 1.9 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.9 section of the CHANGES file.
Older clients and servers interoperate transparently with 1.9 servers and clients. However, some of the new 1.9 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.9 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.9 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.9 libraries. However, a program written for 1.9 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 |
|---|---|---|---|---|
| Prospective blame | 1.9 | 1.8 | any | |
| FSFS format 7 | any | 1.9 | 1.9 | Older formats remain supported. |
| Lock HTTP pipelining | 1.9 | 1.2 | 1.2 | |
| Commit unlocking | 1.2 | 1.9 | 1.2 | |
| Locking multiple files | 1.3 | 1.9 | 1.2 | Over the svn:// protocol. |
| FSX | any | 1.9 | 1.9 | Will not be compatible with 1.10 |
| 1Reminder: when using the file:// repository access method, the Subversion program is both the client and the server. | ||||
Subversion 1.9 uses the same working copy format as Subversion 1.8.
Before using Subversion 1.9 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.9 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.9, 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.9 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.
The Python programming language is an optional dependency. It is required for running the test suite and for building nightly versions, but not for building from packaged releases.
Subversion 1.8 supported Python 2.5 and newer. Subversion 1.9 requires Python 2.7. Older versions of Python are no longer guaranteed to work.
We break compatibility with Python 2.6 and older since it has been end-of-life for nearly two years, and in order to introduce compatibility with Python 3.x in patch releases of the 1.9.x line.
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.9.0 will be numbered 1.10.0.
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.)
The next patch releases on the 1.9.x line will be numbered 1.9.1, 1.9.2, …, as usual.
The default filesystem format is now a new format, numbered 7. (The new command svnadmin info displays the filesystem format number of a repository.) In contrast to previous releases, format 7 is a major overhaul with the general goal of I/O reduction. Major changes include:
As with earlier releases, you may simply run svnadmin upgrade on your repository. However, the new addressing, checksumming and packing scheme will not be used in that case but only in repositories that got created as format 7. For best performance and to enable all features, it is recommended to perform a full dump / load cycle. You can tell whether all format 7 features are enabled by looking for FSFS Logical Addressing: yes in the output of svnadmin info: if that line is printed, then the repository has all format 7 features enabled.
WARNING: Server restart required! Replacing an existing repository with one rebuilt from a dump or restored from backup requires a server restart. This is true for any repository format. Alternatively, you may store the new repository in a different directory and redirect the Apache configuration to use that instead of the old one; svnserve does not offer that option.
The next subsection compares performance characteristics of repositories created directly as format 7 with those upgraded to format 7 from older formats.
The FSFS changes in 1.9 are aimed at better service quality and do not translate into client-side features being available or not. Depending on your setup, some of the improvements may be relevant while others are not. This table shall help you decide what features are relevant to your environment and whether you need to upgrade or dump and load your repositories to reap the benefits.
| Feature | Format 6 or older |
Upgraded to format 7 from older formats |
Created as format 7 not packed |
Created as format 7 packed |
|---|---|---|---|---|
| Reduction in dynamic memory usage1 | yes | yes | yes | yes |
| Saturate 10Gb networks from SVN caches2 | yes | yes | yes | yes |
| Saturate 1Gb networks from OS caches3 | yes | yes | yes | yes |
| svnadmin pack does not block commits | no | yes | yes | yes |
| Full checksum coverage of revision data4 | no | no | yes | yes |
| Quick verification to find external corruption5 | no | no | yes | yes |
| Fast access to cold data on disk6 | no | no | no | yes |
1 Where feasible, temporary buffers have a fixed maximum size now. Other temporary containers have been reduced in memory consumption. 2 If almost all requests can be served from SVN fulltext caches etc., an 8-core server running Apache can saturate a 10Gb network with uncompressed data. It will take 20+ concurrent checkout or export requests to generate that load. 3 If virtually all requests can be served from the OS file cache, a 4-core server running Apache can saturate a 1Gb network with uncompressed data. It will take 2 or more concurrent checkout or export requests to generate that load. 4 Not only user file contents, directories and properties are protected by checksums but also the meta-data tying them together. This only detects external corruption caused by rogue scripts, hard disk failure etc. and will not help against internal corruption caused by faulty SVN logic. 5 Verifies a repository at several 100MB/s and does not slow down with increasing number of revisions. This allows for a much faster health check after system failure. 6 Core feature of format 7. Revision data is read about twice as fast as with older formats. Assuming reading data from disk being 10x slower than from OS caches and a mere 10% OS cache misses, this translates into 30% higher overall throughput with format 7 over previous formats. | ||||
Most users will want to not only svnadmin upgrade to migrate their repositories but to eventually migrate them to format 7. For some, it will be the fast verification feature, others will need the disk I/O improvements. Note that the key I/O characteristics here is the Bandwidth Delay Product of your storage, which is usually between 100kB and 1MB. Even with SSDs you will see a speed-up, unless your storage bandwidth is severely limited.
There is no appreciable difference in CPU usage between the new format and the older ones. Hence, the few setups that work almost entirely from RAM due to very large caches will see little extra performance with format 7. These environments will still benefit from the improved checksum coverage and the support for quick verification.
Make sure to run svnadmin pack on your format 7 repositories at regular intervals. Otherwise, you'll waste performance.
New configuration options are available for tuning read block sizes (format 7 only). They may be changed at any time without causing consistency issues with existing revisions. Changing them is rarely necessary, but may result in slightly improved performance with your specific storage backend or when dealing with multi-TB repositories. See the commentary in fsfs.conf for more information. (You may have to create a new repository to see the documentation about these settings in fsfs.conf.)
[io] block-size = 256 l2p-page-size = 32768 p2l-page-size = 16384
FSFS uses a combination of two methods to reduce on-disk data size. First, we determine the changes (delta) against some previous version of the same file. This process can be controlled by fsfs.conf settings since 1.8. The result would then be compressed using ZIP/deflate. That relatively costly operation limits commit speeds of large incompressible files. You may now specify the compression level in fsfs.conf or disable compression entirely:
[deltification] compression-level = 0
Directory and property deltification are now enabled by default for FSFS repositories in 1.6 format or newer. Various optimizations were added to the delta creation code to minimize the read amplification effect and to provide a net speedup when using deltification vs. not using it. Keep txdelta caches enabled when using directories deltification. Otherwise, you may suffer a significant performance hit.
To prevent Subversion 1.9 from deltifying properties and directories in older format repositories, set the following options in the repository’s fsfs.conf file:
[deltification]
enable-dir-deltification = false
enable-props-deltification = false
The caching logic has been enhanced to cope with the extra load caused by the access indirection introduced in FSFS format 7. While most of this simply means more net speed, some changes may affect your configuration settings.
Where the svnadmin tool covers typical administrative tasks in a mostly back-end agnostic way, svnfsfs is a specialist tool for analyzing and manipulating of FSFS repositories. It is not intended for everyday use.
The fsfs-stats tool first released with Subversion 1.8 has been replaced by the svnfsfs stats sub-command and is no longer part of Subversion 1.9. Both produce similar output.
During forensics or data recovery, it is necessary for experts to directly "look into" the raw database files. While the FSFS on-disk format is fully documented, the indirect addressing and reordering added in format 7 makes it hard for humans to trace internal references. This is where the svnfsfs dump-index sub-command is used. It produces a table describing all items in revision and pack files:
$ svnfsfs dump-index /path/to/repo -r0
Start Length Type Revision Item Checksum
0 11 drep 0 3 60232b75
11 59 node 0 2 403dbe48
6a 1 chgs 0 1 f28a4f1d
Because the index information must always match the actual file contents, updating the index data after every revision / pack file manipulation is mandatory in format 7. svnfsfs load-index allows you to do that. It consumes the same table format as produced above, except that the checksum field is optional and will be ignored if given. See the known issues list for problems in released versions of that tool.
WARNING: Be sure to create a backup of your repository before trying to manipulate it through svnfsfs !
In 1.9.0, the svnfsfs load-index does not work as described in its documentation. The following restrictions and workarounds apply:
Start Length Type Revision Item
0 0 none 3000 0
0 25a chgs 3999 1
25a 3b9 chgs 3998 1
...
These problems have been fixed in 1.9.1.
Since its inception 10 years ago, FSFS has been improved greatly and the improvements provided with format 7 are another major step forward. However, there are limits to what can be done in a meaningful and backward compatible way. FSX is being designed to overcome these limitations. Here some of the intended improvements:
Development of FSX was started as a fork of FSFS to guarantee functional completeness and testability. The current code still contains remnants of FSFS legacy code and not all of the above improvements have been implemented yet. Later releases will close the gap and remove transitional code.
WARNING: FSX is NOT production ready. DO NOT USE IT – unless you have read this section carefully and understand the limitations of FSX in Subversion 1.9.
FSX is nowhere near as stable and reliable as FSFS. Furthermore, there will be no support for 1.9-style FSX repositories in 1.10 (see Incompatibility). Think, therefore, of all data in a FSX repository as being potentially corrupt. Its improved performance and storage characteristics, though, might make FSX a viable option for the following use-cases:
If you experiment with FSX, please let us know your findings. This is your chance to get your use-case covered before storage format and principles of operation are set in stone.
The FSX code and storage representation is in an intermediate state with respect to the feature set that its developers have in mind. For as long as it keeps its experimental status, there will be neither forward nor backward compatibility between FSX repositories of different Subversion feature releases. Subversion 1.10 and later will recognize 1.9 FSX repositories and error out on them. You may use dump and load to upgrade an FSX repository from one release to another.
Dump and load is also the only upgrade path between FSFS and FSX.
Finally, there is no guarantee that FSX will eventually be released at all; as an experimental backend, we make no promise that future releases will support reading or writing FSX repositories.
The new svn auth sub-command can be used to view or remove authentication credentials saved in any of the supported password caches. Authentication credentials include usernames, passwords, SSL certificates, and SSL client-certificate passphrases.
Specific credentials can be selected with an arbitrary number of pattern arguments which are matched against the attributes of each credential. For example, view cached SSL certificates for the apache.org domain, matched via credential kind (svn.ssl.server) and authentication realm and certificate subject (apache.org):
$ svn auth svn.ssl.server apache.org ------------------------------------------------------------------------ Credential kind: svn.ssl.server Authentication realm: https://svn.us.apache.org:443 Subject: C=US, ST=Maryland, L=Forest Hill, O=The Apache Software Foundation, OU=Infrastructure, CN=*.apache.org Valid from: 2015-04-29 02:00:00 +0200 (Wed, 29 Apr 2015) Valid until: 2017-04-30 01:59:59 +0200 (Sun, 30 Apr 2017) Issuer: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 Secure Server CA - G4 Fingerprint: 4ad722dd0442043657d176f9c81aab66094d4223 Hostnames: *.apache.org Automatic certificate validity check failed because: The certificate's Common Name (hostname) does not match the remote hostname. Credentials cache in '~/.subversion' contains 1 matching credentials
For more information, see svn help auth.
The svn info command can now display the value of one of the fields and nothing else, for easier consumption by scripts.
Subversion 1.8 and earlier had two output modes: the default, human-oriented output, mode and the XML mode for scripted use. Subversion 1.9 adds a third output mode, whereby exactly one attribute will be displayed:
## Display the youngest revision of a repository: % svn info --show-item=revision https://svn.apache.org/repos/asf/subversion/trunk 1693514 ## Find the root directory of a working copy: % svn info --show-item=wc-root /home/jrandom/src/svn/trunk
Incidentally, Subversion will also attempt to offer the correct selector name if the argument was misspelled:
% svn info --show-item=wcroot svn: E205000: Try 'svn help info' for more information svn: E205000: 'wcroot' is not a valid value for --show-item; did you mean 'wc-root'?
The list of valid arguments to --show-item may be found in its help message, svn help info. As of 1.9, the valid values are kind, url, relative-url, repos-root-url, repos-uuid, revision, last-changed-revision, last-changed-date, last-changed-author, and wc-root.
The --no-newline argument instructs svn not to emit a cosmetic newline (\n) after the value.
The svn propget sub-command has a new --no-newline option. It is equivalent to the old --strict option which is now deprecated.
The new --trust-server-cert-failures option is intended to be used by scripts which for some reason must accept SSL certificates which fail validation for various reasons (e.g. expired certificates).
If at all possible, fixing a certificate problem is preferable to using this option.
The --trust-server-cert-failures option only works in conjunction with the --non-interactive option.
Previous versions of Subversion in non-interactive mode could only ignore certificates with an unknown certificate authority, but expired or otherwise invalid SSL certificates could not be accepted.
The svn copy sub-command now supports a new --pin-externals option. Use of this option is recommended when creating tags.
If this option is used, svn copy pins the URLs in svn:externals properties in the copied tree to their current revision, such that externals keep their current contents when the copied tree is checked out at a later time.
Note that external references within externals cannot be pinned as this would require svn copy to make commits to any foreign repositories referenced by externals.
The svn cleanup command has new --remove-unversioned and --remove-ignored options which can be used to remove unversioned and ignored files from the working copy.
svn cleanup can now recurse into externals with the new --include-externals option.
In the interactive conflict resolver, the (m) merge command now tries an external file merge tool if one is defined. Else the internal file merge tool is used.
In Subversion 1.8, the (m) merge command always triggered the internal file merge tool. The (i) internal merge tool command was added to Subversion 1.9 and has the old meaning of the (m) merge command.
The status command, when given the --show-updates (-u) flag, can now compare the working copy to specific remote revision, given by the -r (--revision) flag. (Previously, the remote revision would default to HEAD.)
Our best practices suggest that projects should branch and merge at the project root level. Each merge will then usually change the svn:mergeinfo property at the project base folder. To commit that change, pre-1.9 servers require the client to have the latest version of that base folder. Whenever there is a commit in that tree, its base folder will get a new revision as well, though. Thus, in large, busy projects, it is likely that by the time a large merge commit would actually have reached its finalization phase, some other commit got through and the merge commit is rejected for being out of date.
Subversion 1.9 now allows to modify directory properties based on old revisions as long as the directory contents itself did no change. Directory contents changes would either be property changes, added or removed entries. Sub-tree or file contents changes no longer prevent the property change from going through. Of course, true file and tree change conflicts will still result in out-of-date errors.
This new behavior is not restricted to svn:mergeinfo changes but applies to any directory properties. Changes to svn:ignore are another common scenario previously prone to update / commit / out-of-date races.
In threaded mode, svnserve starts one thread per network connection - potentially consuming a large amount of resources. Subversion 1.9 now uses a thread pool with a configurable minimum and maximum number of threads. Use the command line options --min-threads and --max-threads if the defaults don't suite your needs.
Once there are more connections than threads, the threads will serve incoming requests in a round-robin fashion. If all those requests are long-running reports like checkout or export, connections with waiting requests may eventually time out.
Whether or not the new options are available depends on the platform and APR capabilities. Also, the default for --max-threads is lower on 32 bit systems than on 64 bit ones. Run svnserve --help to see your system's defaults and whether the options are available at all.
This prints detailed format information for the given repository.
$ svnadmin info /repos/apache/ Path: /repos/apache UUID: ac336b0e-000b-11e0-b354-23d019ddd9ed Repository Format: 5 Compatible With Version: 1.8.0 Repository Capability: mergeinfo Filesystem Type: fsfs Filesystem Format: 6 FSFS Sharded: yes FSFS Shard Size: 1000 FSFS Shards Packed: 1631/1631 FSFS Logical Addressing: no Configuration File: /repos/apache/db/fsfs.conf
Packing now takes a cache size parameter (-M) which is used for efficient operation on FSFS format 7 repositories.
$ svnadmin pack -M 1000 /path/to/repository
Packing is paramount to FSFS format 7 performance; do it often. To make this feasible, packing FSFS format 7 repositories will no longer block commits for the whole time of its execution. Instead, individual commits may now get delayed by much shorter periods of time, usually by less than one second.
Verification will terminate by default once a problem has been found. The new --keep-going option instructs svnadmin to continue with the next revision such that multiple issues may be found in a single run. If a revision has multiple issues and depending on the verification logic, still only the first problem may be reported.
The new --check-normalization option reports any path names within the same directory or svn:mergeinfo property which differ only in character representation (e.g. Unicode precomposed and decomposed character representations), but are otherwise identical.
Thorough verification is expensive and becomes slower as the repository history grows. The new --metadata-only flag will skip the expensive internal consistency checks and reconstruction of all user data. In format 7 repositories, this will still perform a quick on-disk checksum test of all data in rev / pack files but will only detect cases where external forces (storage crash, rogue scripts etc.) modified committed data. Also, the checksums are weaker (about a 1 in a billion chance that a random change remains undetected) than the ones used to protect the user data. If you suspect internal repository corruption caused by a bug within SVN itself, you still need to run a full verification.
The setrevprop command now takes the --transaction flag. It can be used from pre-commit hooks to set revision properties on the transaction (commit-in-progress) before it becomes a commit.
The new delrevprop command deletes a revision property from either a revision or a transaction. It complements setrevprop which adds or modifies revprops.
The svnadmin load command has a new flag, --ignore-dates, which causes it to ignore revision datestamps (svn:date) in the input dumpfile.
With Subversion 1.9 this tool is now part of the standard set of SVN binaries. In keeping with the existing programs, it has been renamed to svnbench.
To investigate bottlenecks in svn blame, we added a protocol driver variant of it to svnbench. The new null-blame sub-command requests the same data from the server as the normal command line client and shows a summary of the amount of data received.
$ svnbench null-blame -g http://example.org/repo/path/to/file
34 revisions
31 deltas
1,161,077 bytes in deltas
When a text conflict occurs (and is not resolved by the interactive conflicts resolver during svn update, svn switch or svn merge), conflicts markers are written into the conflicted file. Previous versions of Subversion would render conflict markers as follows:
Unconflicted lines <<<<<<< .mine Contents of the file in the working copy (including local modifications) ======= Contents of the file in the revision being updated to >>>>>>> .r2 Unconflicted lines
As of Subversion 1.9, conflict markers would be rendered with information on the base (called "older" in diff3 parlance):
Unconflicted lines <<<<<<< .mine Contents of the file in the working copy (including local modifications) ||||||| .r1 Contents of the file in the working copy's BASE revision ======= Contents of the file in the revision being updated to >>>>>>> .r2 Unconflicted lines
Here, one resolves the conflict by manually applying to the <<<<<<< hunk the same changes that would transform the ||||||| hunk into the >>>>>>> hunk. For example, the following conflict:
Unconflicted lines
<<<<<<< .mine
"Hello hello, world!"
||||||| .r1
"Hello, world!"
=======
"Hello, ${name}!"
>>>>>>> .r2
Unconflicted lines
should be resolved to:
Unconflicted lines
"Hello hello, ${name}!"
Unconflicted lines
The three-way conflict display was already used by property conflicts and by the interactive conflicts resolver in previous releases of Subversion.
The old, two-way conflict markers output can be obtained by setting diff3-cmd in the Subversion runtime configuration (or via the --config-option or --diff3-cmd command-line options) to a diff3 command that generates two-way conflict markers. Your system may already include such a diff3 program; one is also included with Subversion and can be installed via make install-tools (Unix) or by building the diff3 or __MORE__ targets (Windows). On a typical Unix system, simply setting diff3-cmd=diff3 will restore two-way conflict markers.
Subversion 1.9 adds to the included diff3 program a --conflict-style marker that can be used to explicitly choose among two-way conflict markers, three-way conflict markers, and a few other options. That program can be used independently of Subversion anywhere a diff3 command is needed.
The blame command can now show not only when the last change to each line of a given file was, but also when the next change will be.
For example, to see for each line in revision 3 of README.txt what the next revision that changed (or removed) that line would be, run svn blame -r HEAD:3 README.txt. (You may need to pass a peg revision if the file had been renamed since r3.)
In the blame command, the range -r M:N always means "display information about the file at revision N". If the range is "forward" (M<N) then the normal blame algorithm is used, displaying for each line in the file when it was added or last changed; if the range is "reversed" (M>N) then the above-described sense is used, describing for each line in rN when it was first changed (or deleted) after rN and before rM.
Here is an example, from Subversion's own repository. The autoconf macro SVN_CHECK_FOR_DUNDER_BUILTINS was present in r1509167 but is not present in HEAD. The blame command can determine the revision in which the macro was removed:
% svn blame -r HEAD:1509167 svn-macros.m4 ⋮ 1509168 danielsh AC_DEFUN([SVN_CHECK_FOR_DUNDER_BUILTINS],
And indeed, svn diff -c r1509168 shows that revision deleting the definition of the macro.
When locking, or unlocking, multiple files in a single operation over HTTP the client will use HTTP pipelining for the individual WebDAV LOCK and UNLOCK requests. This makes the operation faster particularly on connections with large network latency. While HTTP pipelining is new for LOCK and UNLOCK the client was already using it for GET requests.
Subversion locks, the locks that prevent commits from other working copies, are stored in the repository. When adding or removing locks the FSFS backend can now operate on several locks at once. This reduces the amount of disk IO when handling multiple locks and is significant when the total number of locks in the repository is large, 100,000 say.
The default behaviour for commits is to automatically release locks after a successful commit and this takes advantage of the more efficient lock process. In previous releases the disk IO involved in releasing the locks would sometimes be greater than that involved in creating the new revision.
Clients using the svn:// protocol will also benefit from the more efficient lock handling when locking or unlocking multiple files in a single operation. Clients using HTTP will not get this benefit since the client still sends multiple, pipelined, LOCK and UNLOCK requests, one for each file.
The post-lock and post-unlock hooks receive multiple paths via standard input. In previous releases the repository backends always operated on a single path at a time so only one path was ever passed to the hook. In 1.9 when multiple paths are locked or unlocked in a single operation multiple paths will be passed to the hook.
The pre-lock and pre-unlock hooks continue to be passed a single path as a parameter.
Subversion's Apache module, mod_dav_svn, can display statistics that describe the status of the FSFS cache for the running Apache instance. To enable this define a Location block in the Apache configuration file:
<Location /svn-status>
SetHandler svn-status
</Location>
Visiting the Location with a web browser will display statistics about the FSFS cache for the running Apache instance. If Apache is configured to use multiple processes, most Unix deployments, the statistics will only apply to the process that served the GET request and repeating the request will cause different processes to be queried.
There are some known issues in the Subversion 1.9 releases. These may be fixed in later 1.9.x releases.
See issue #4598 "No-op changes no longer dumped by 'svnadmin dump' in 1.9".
It has always been possible, in atypical cases, for a commit to mark a file as 'changed' without actually changing the file's text and/or properties to a different value. Starting from 1.9.0, svnadmin dump still outputs a record for such a file, including a header saying that the action is 'change', but no longer appends a block describing the new text for the file. (And similarly for properties, perhaps? TBD.) When svnadmin load (1.8 or 1.9) reads this dumpfile, it does not record any change in the repository for such a file.
One user-visible effect is that, after dump and load, 'svn log -v' will no longer list the path of such a file in its list of 'changed paths'.
A fix for this problem has been included in the 1.9.3 release.
If there are concurrent commits to the same repository, they may randomly fail with an "out of date" error message without actually being in conflict. The problem presents itself to the user like any legitimate out-of-date condition and retrying the commit as usual will fix the problem.
This problem is not new to Subversion 1.9 and limited to repositories with high commit frequencies. Triggering it requires either pre-1.7 clients, a pre-1.7 server or a server that has HTTPv2 explicitly disabled via the SVNAdvertiseV2Protocol off option. To avoid the problem, consider upgrading clients and configuring the server to use the HTTPv2 protocol.
svnserve and local repository access are not affected.
Subversion 1.9 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.
Subversion 1.9.0 introduces the use of HTTP pipelining for locking/unlocking multiple files. While SVN detects whether HTTP pipelining is supported (and falls back to non HTTP pipelining mode, if it isn't), issues can arrise, if there are flaws or bugs with any of the protocols/applications involved in processing pipelined HTTP requests.
Especially, if there are older proxies present in the network topology, it's possible that you run into issues, since being a technology which was introduced in HTTP/1.1 (and the full performance benefit is not expected unless you are using HTTP/2), this feature might have not been extensively tested by your proxy vendor.
To troubleshoot whether the proxy is causing an issue, try to lock/unlock multiple files bypassing the proxy. If that works, please get in touch with the proxy vendor to notify him about the problem and ask for support.
It's also appreciated, if you would let the SVN developers know about the effected proxy via the users mailing list so this troubleshooting section can be updated.
At the moment there is one potentially known proprietary proxy running into this issue: Java-SSL-tunnel. See Tortoise SVN mailing list .
The Subversion 1.7.x line is no longer supported. This doesn't mean that your 1.7 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.7.x versions, and will not make any more 1.7.x bugfix releases.