Apache Subversion 1.7 Release Notes

What's New in Apache Subversion 1.7

Apache Subversion 1.7 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.6.x is also in 1.7, but 1.7 contains features and bugfixes not present in any earlier release. The new features will eventually be documented in a 1.7 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.7 section of the CHANGES file.

Compatibility Concerns

Older clients and servers interoperate transparently with 1.7 servers and clients. However, some of the new 1.7 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.7 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.7 servers use the same repository format as Subversion 1.6. Therefore, it is possible to seamlessly upgrade and downgrade between 1.6.x and 1.7.x servers without changing the format of the on-disk repositories. (This is not correct in general for any pair of 1.x and 1.y servers, but happens to hold for 1.6 and 1.7.) If new 1.7 features were enabled on the server (in the hooks or server configuration files), they will, of course, have to be disabled prior to reverting back to a 1.6 server.

Subversion 1.7 clients use a new working copy format. Subversion 1.7 clients cannot use Subversion 1.6 (and earlier) working copies. Existing working copies created with Subversion 1.6 and earlier need to be upgraded before they can be used with a Subversion 1.7 client (see below for details).

Subversion 1.7 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.7 libraries. However, a program written for 1.7 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. For Subversion 1.7, these errata are mostly limited to libsvn_wc, with one notable exception: libsvn_ra_serf's approach to driving the svn_delta_editor_t interfaces (provided to it indirectly via calls to the svn_ra.h interfaces).

New Feature Compatibility Table

New Feature Minimum Client1 Minimum Server Minimum Repository Notes
HTTPv2 1.7 1.7 any Permutations of older client/server combinations will continue to function at the pre-1.7 feature level. Server-side configuration changes might be required for optimal performance with clients that use serf.
WC-NG 1.7 any any 1.6 working copies cannot be used with 1.7 and will not be upgraded to the new 1.7 format automatically.
svnrdump 1.7 1.4 (dump)
1.7 (load)
any See the full entry, below for discussion of known issues.
svn patch 1.7 any any
atomic revprop changes 1.7 1.7 any Fixes a race condition in svnsync (issue #3546).
reduced subtree mergeinfo recording 1.7 any any If both pre-1.7 clients and 1.7 clients are used to perform merges to the same branch, the pre-1.7 clients may experience slower merge performance.
server performance tuning any 1.7 any Purely server-side configuration. file:// access in 1.7 clients will use the default settings.
1Reminder: when using the file:// repository access method, the Subversion program is both the client and the server.

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

Improved output of svn update for multiple working copies

Improvements have been made to the output of svn update when updating multiple working copies at once (see issue #3693). Below is an example of the new output:

  $ svn up subversion svncorp UNVERSIONED
  Updating 'subversion':
  At revision 1037740.
  Updating 'svncorp':
  At revision 288.
  Summary of updates:
   Updated 'subversion' to r1037740.
   Updated 'svncorp' to r288.
  Summary of conflicts:
   Skipped paths: 1

svn diff now shows property changes as unidiff

svn diff now shows textual property changes in unidiff format, except for svn:mergeinfo properties. Below is an example of the new output:

  $ svn diff
  Index: gamma
  --- gamma       (revision 23)
  +++ gamma       (working copy)

  Property changes on: gamma
  Modified: svn:externals
  ## -1,3 +1,3 ##
   ^/branches/gamma gamma-external
  -^/trunk/alpha alpha-external
  +^/trunk/beta beta-external
   ^/trunk/epsilon epsilon-external
  Index: beta
  --- beta        (revision 23)
  +++ beta        (working copy)

  Property changes on: beta
  Added: svn:eol-style
  ## -0,0 +1 ##

Error and warning numbers now reported

The output of svn now contains an error number or warning number with every error. The following example illustrates these changes.

   % svn info
   svn: E155007: '/home/CIA-91' is not a working copy

These error values are useful as search keywords. Under the hood, these error codes correspond to the API error codes used by Subversion and APR. For programming to our API's, it's possible to convert a numeric error code to a symbolic one via the which-error.py script (first included in Subversion 1.3.0):

   % ./tools/dev/which-error.py 155007

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.

Case sensitivity of authz access rules

Prior to this release, the section headers in Subversion's authz access files—which contain repository names and repository filesystem paths—were parsed in a case-insensitive fashion. That's been fixed in this release. 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 access to items in your repositories being unexpectedly denied—or granted—as a result of upgrading to Subversion 1.7. Please review all authz access files for case correctness. (For details, see issue #3781).

Incompatible FSFS changes since 1.7.0-alpha3 for packed repositories

Subversion 1.6 introduced support for packing FSFS revision files, and Subversion 1.7.x alpha releases (up to 1.7.0-alpha3) supported packing of revprops into an SQLite database. This support is not present in the final release (see issue #3952 for the reason). Any FSFS-backed repositories that were svnadmin created or svnadmin upgraded by svnadmin from a nightly build or from an alpha release of the 1.7.x line are not supported by the final 1.7.0 release. It is required to dump these repositories using an svnadmin built from the 1.7.0-alpha3 release (or to svnsync them using a source server running 1.7.0-alpha3) in order to upgrade them for the 1.7.0 release.

Subversion 1.7 will complain when it encounters such repositories, with the following error:

subversion/libsvn_fs_fs/fs_fs.c:1083: (apr_err=160043)
svnadmin: E160043: Found format '5', only created by unreleased dev builds;
   see https://subversion.apache.org/docs/release-notes/1.7#revprop-packing

We reiterate that this lack of upgrade path is within the latitude of our policy for pre-releases. We may provide in the future a script to downgrade a repository in-place to the format supported by both 1.6 and 1.7. (We will welcome contributions of such a script.)

We plan to reintroduce revprop packing in a future release; see issue #3944 for details.

'svn remove' now removes directories from disk immediately

The svn remove command now removes directories from disk immmediately. In Subversion 1.6, directories were scheduled for deletion but kept on disk to retain meta-data stored in the .svn subdirectory. With the new working copy format introduced in Subversion 1.7 it is no longer necessary to keep the removed directory on disk. This also facilitates better handling of directory replacements in the working copy (see issue #3468 for details).

If the --keep-local option is used, svn remove will keep the removed directory on disk.

Large versioned directories in FSFS repositories

Subversion 1.7 introduces a new data cache implementation. In contrast to version 1.6, we now limit the size of that cache to give better control over the total amount of memory consumed by the server process. On the flip side, it also limits the size of directories that can be cached and, therefore handled, efficiently. If you version directories with more than 10,000 entries, you must change the cache settings (see server performance tuning for details).

New Features

Working Copy Metadata Storage Improvements (client)

Subversion 1.7 features a complete re-write of the working copy metadata management system of Subversion, code named WC-NG. The old system was one of the first parts of Subversion written, and over time had grown difficult to maintain and extend. WC-NG is intended to provide an immediate performance improvement, while also enabling many future feature enhancements.

Although Subversion 1.7 does not introduce these new features, the improvements in the working copy storage make them much more likely to appear in future releases.

A number of known (and unknown) bugs have been fixed by the new working copy metadata system (see issue #3357).

Centralized Metadata Storage

A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every directory in the working copy, Subversion 1.7 working copies have just one .svn directory—in the root of the working copy. This directory includes (among other things) an SQLite-backed database which contains all of the metadata Subversion needs for that working copy.

Even though the data is stored in a structured format, the relationships between the data are complex. We highly discourage external tools from modifying the data held in this database, as such modification is likely to result in working copy corruption.

WARNING: It is not safe to copy an SQLite file while it's being accessed via the SQLite libraries. Consequently, duplicating a working copy (using tar, cp, or rsync) that is being accessed by a Subversion process is not supported for Subversion 1.7 working copies, and may cause the duplicate (new) working copy to be created corrupted. (See issue #3596 for details.)

Pristine Contents

Subversion keeps a record of the unmodified contents of all files in the working copy. Historically, these have been called text-bases, but in Subversion 1.7, they have received a new name, and a new home. With the centralization of metadata, the text-bases have been renamed pristines, and are now located in the same .svn directory as the working copy metadata.

The pristines are stored by checksum in a sharded format. Any files in the working copy which have the same pristine content will now share references to the pristine store, making such working copies slightly smaller. Running svn cleanup will remove any pristines which are no longer needed by the current state of the working copy.

Note: In 1.7, we recommend to run svn cleanup periodically in order to reclaim the disk space of unreferenced pristines. We expect a future Subversion release to purge unreferenced (and thus unused) pristines automatically; see issue #4071 for details.

Upgrading the Working Copy

Subversion 1.7 introduces substantial changes to the working copy format. In previous releases of Subversion, Subversion would automatically update the working copy to the new format when a write operation was performed. Subversion 1.7, however, will make this a manual step. Before using Subversion 1.7 with their working copies, users will be required to run a new command, svn upgrade to update the 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.

Note: Subversion 1.7 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.7, a 1.6 client must be used to run svn cleanup on all working copies that require cleanup. Likewise, Subversion 1.7 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.

We regret these limitations, but we had to introduce them in order for 1.7 to ship timely and without overcomplicating the internals. If your working copy does not upgrade cleanly, please check out a new one.

Improved HTTP protocol usage (client and server)

Over the years, many people have complained about the performance issues with Subversion's use of HTTP as a repository access mechanism. This largely stems from the developers' original intent to implement as much of the WebDAV DeltaV specification as possible. Alas, this specification was not widely implemented, so none of the supposed benefits of the DeltaV overhead ever materialized.

Subversion 1.7 offers a simpler HTTP protocol variant that can be used when connecting to supported servers. This simpler protocol (sometimes referred to as HTTPv2) requires fewer client-server round trips to establish a connection, making Subversion much more performant on high-latency network connections. Subversion's Serf-based repository access library (which will become the default library for HTTP in Subversion 1.8) has received all of the protocol changes scheduled for 1.7, affecting both commit and read operations; the older Neon-based library has received the most important and high-impact of these changes, too.

As mentioned in the compatibility table, Subversion 1.7 will only use HTTPv2 when connecting with a 1.7 (or greater) server, but will continue to use existing protocols when communicating with earlier versions of Subversion. Likewise, older clients will only use the old protocol when connecting to a Subversion server, regardless of version.

New remote dumpfile tool: svnrdump (client)

Subversion 1.7 adds a new tool to the client's toolbox: svnrdump. svnrdump replicates the functionality of svnadmin dump and svnadmin load, but works on remote repositories, instead of needing administrator (local filesystem) access to the source or target repository.

svnrdump load race condition

Note that svnrdump load can suffer from a race condition in its locking algorithm when run against a 1.6 or earlier server. The race condition is only applicable if multiple svnrdump load processes may attempt to write concurrently to a single repository. This is the same problem that the new atomic revprop changes feature fixes for svnsync (see issue #3546), and the same server-side workaround is available.

Server administrators who would like to block their users from committing via svnrdump load may do so by installing the following pre-revprop-change script:

if [ x"$PROPNAME" = x"svn:rdump-lock" ]; then
  echo "'svnrdump load' disabled by the server administrator" >&2
  exit 1
exit 0

This hook script suffices to protect repositories from accidental use of svnrdump load. It does not (and cannot) protect the server from users who intentionally recompile svnrdump in order to bypass this restriction.

svnrdump dump and libsvn_ra_serf editor driving don't mix

The svnrdump dump command is more strict in its expectations from the network access library than the API permits it to be. This problem manifests itself in particular with the ra_serf HTTP access library, as documented in issue #4116. A workaround is to use the ra_neon HTTP access library (which is the default).

The problem does not affect other executables (such as svn and svnadmin). It also does not affect svnrdump when the default HTTP access library, ra_neon, is used. Third-party API consumers should not expect to be able to use all the orderings permitted by the delta editor API when the editor receiver is svnrdump dump.

This problem is related to, but not the same as, ra_serf's dishonouring of the delta editor ordering rules.

New feature: svn patch (client)

Subversion 1.7 features a new subcommand called svn patch which can apply patch files in unidiff format (as produced by svn diff and other diff tools) to a working copy.

svn patch will apply unidiff changes to existing files just like third party patch tools. It will also add newly created files to version control, and delete files and directories which are left empty after patching. Keywords and newlines are also handled automatically if the svn:keywords and svn:eol-style properties are set on patched files.

svn diff will now produce unidiff output for Subversion property changes, and svn patch is able to apply these changes to properties (except for svn:mergeinfo, see issue #3747).

When a patch does not apply cleanly some or all changes listed in the patch might be rejected. But svn patch currently does not mark files with rejected changes as conflicted (see issue #3565). Files which weren't patched successfully can be committed without being touched by svn resolve first. This problem will be addressed in a future release of Subversion.

A new API for parsing unidiff patch files has been added to libsvn_diff. A new API for applying unidiff patches to a working copy has been added to libsvn_client.

Enhancements and Bugfixes

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.7.0 section in the CHANGES file for a complete list.

svn log can now print diffs

svn log accepts the new --diff option which causes it to show changes committed in a revision as a unified diff. Below is example output:

  $ svn log --diff -r1033146 https://svn.apache.org/repos/asf/subversion/trunk
  r1033146 | hwright | 2010-11-09 19:40:46 +0100 (Tue, 09 Nov 2010) | 3 lines

  * subversion/libsvn_wc/wc_db.c
    (svn_wc__db_op_copy): Remove unused variable.

  Index: subversion/libsvn_wc/wc_db.c
  --- subversion/libsvn_wc/wc_db.c	(revision 1033145)
  +++ subversion/libsvn_wc/wc_db.c	(revision 1033146)
  @@ -3061,7 +3061,7 @@ svn_wc__db_op_copy(svn_wc__db_t *db,
                      apr_pool_t *scratch_pool)
     svn_wc__db_pdh_t *src_pdh, *dst_pdh;
  -  const char *src_relpath, *dst_relpath, *dst_op_root_relpath;
  +  const char *src_relpath, *dst_relpath;
     apr_int64_t dst_op_depth;


svn update now accepts the --parents option

svn update now accepts the --parents option. This option removes the need to manually create missing parent directories when adding additional items to a sparse working copy.

For example, adding 3 files from different directories to a sparse working copy required creating each file's parent directories first:

   $ svn co --depth=empty ${PROJECT_ROOT_URL} wc
   $ svn up --depth=empty wc/A wc/A/D wc/A/D/G wc/A/D/H wc/A/B wc/A/B/E
   $ svn up wc/A/D/G/pi wc/A/D/H/omega wc/A/B/E/alpha

This becomes much easier with the new --parents option:

   $ svn co --depth=empty ${PROJECT_ROOT_URL} wc
   $ svn up --parents wc/A/D/G/pi wc/A/D/H/omega wc/A/B/E/alpha

New subcommand: svn relocate

A new svn relocate subcommand has been added. It points a working copy to a different repository root URL, serving the same purpose as the old svn switch --relocate syntax which has now been deprecated.

svn switch now checks ancestry

svn switch now checks that the working copy item being switched shares common version control history with the URL to which it is being switched.

This change was made to protect users from the unpleasant side effects of oft-mistyped switch commands, such as accidentally running svn switch ^/branches when you instead meant to run svn switch ^/branches/SOME-BRANCH. As of version 1.7, Subversion will check to see if the source URL and the target working copy item are ancestrally related and, if they do not, the switch operation will fail with an error.

   $ svn switch ^/branches
   svn: E195012: Path '.' does not share common version control ancestry
   with the requested switch location.  Use --ignore-ancestry to disable
   this check.

What is meant by "ancestrally related"? In short, it means that if you were to compare all the paths and revisions that each of these two version controlled items has occupied over time — its current repository location plus all previous ones, back through all the copies and moves in its history — those two sets would overlap.

As noted in the previous example's error message, this ancestry check — which does come at some performance cost — may be disabled by passing the --ignore-ancestry option to the svn switch command.

svn diff can show copied files as if they were newly added

When svn diff shows a copied file, it usually shows how the copied file differs from the file it was copied from. Sometimes this isn't the desired form of output. There are situations where a copied file needs to appear in its entirety, for instance when producing a patch file to be applied elsewhere with a patch tool (such as svn patch).

In Subversion 1.7, svn diff takes a new --show-copies-as-adds option which causes copied files to be shown in their entirety, just like newly added files are shown.

svn diff can show git-style diff annotations

svn diff takes a new --git option which causes it to produce extra annotations denoting added, deleted, and copied files. This extended diff format was inspired by git-diff.

svn diff --git is intended to produce patches which are compatible to git-apply, but there are limitations due to differences between Subversion and git:

  • svn diff currently cannot display rename information. Renames are always shown as a copy and a delete.
  • All paths in patches are shown relative to the repository root to avoid ambiguity. It is possible that the numbers of leading path components on the left and right side of the patch differ, for instance if a diff between /trunk and /branches/mybranch is shown. This may prevent git-apply from applying such patches without modification.

In a future release of Subversion, svn patch will receive support for the extra annotations produced by svn diff --git, so that additions, copies, renames, and deletions can be handled explicitly rather than implicitly.

The same diff format extensions are also supported by Mercurial.

svn merge help text has been enhanced

The help text for the svn merge command has been enhanced. It now explains common use cases and includes small examples, making it more useful for quick reference.

New subcommand: svnlook filesize

A new svnlook filesize subcommand has been added. It returns the size of a given path in the repository, for a given revision or transaction. This is a constant-time operation regardless of the size of the file. In pre-commit hooks wanting to block commits with too large files, svnlook filesize can now be used instead of the much more costly workaround via svnlook cat.

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

There are too many new and revised APIs in Subversion 1.7.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.

As noted above, a small number of APIs in libsvn_wc have slightly changed functionality from their historical roots. Each of these cases has been documented as an errata, detailing the impact of these changes. All of the errata were the result of behavior which was deemed buggy, and the API changes are an attempt to fix these bugs. The circumstances under which each is triggered are relatively rare, and we anticipate the actual impact to end users will be minimal.

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

JavaHL Updates

Due to the move to the Apache Software Foundation, the JavaHL bindings have been similarly moved to a new package: org.apache.subversion. The old package still exists, and will continue to ship for backward compatibility reasons, but we recommend comsumers switch to the new package, as only it will continue to be updated.

Also, JavaHL now requires Java 1.5 to compile. In addition, many of the APIs in the new package have been switch to use generics, and other Java 1.5 language features.

Bug fixes (client and server)

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

Serf HTTP library improved and stabilized (client)

The libsvn_ra_serf repository access library has received a lot of improvements and stabilization. The design of serf facilitates future performance improvements that are impossible to achieve with neon. There were plans to make serf the default HTTP access library for the 1.7 release. But because of some remaining issues (for instance issue #3979, issue #3980, and issue #3981), Subversion 1.7 still uses neon by default. Remaining problems are mostly due to insufficient infrastructure deployed in the wild wild web, such as HTTP proxies that do not support HTTP/1.1. Workarounds for these problems will be implemented for the next release. serf will become the default HTTP access library in Subversion 1.8.

In the meantime, we encourage all users to try serf with Subversion 1.7 and report any problems. Successful test reports are appreciated as well. Tests in networks that use HTTP proxies or enterprise authentication are particularly helpful. You can configure which library the client should use on a default or host-by-host basis by setting the http-library variable in the client-side servers configuration file (~/.subversion/servers).

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.

Because serf clients issue a larger number of HTTP GET requests than neon clients it is possible that serf clients cause quicker growth of httpd server logs than neon clients do. As of 1.7.3, the httpd error logs may also grow more rapidly with serf clients than with neon clients; see r1239697.

Known issues with svnrdump that manifest when the latter uses the ra_serf library for HTTP access are documented under the 'svnrdump' section of this document.

Improved handling of HTTP redirects (client)

In the past, when the Subversion client encountered an HTTP redirect response from the server, it displayed an obtuse, and rarely-useful error message. Subversion 1.7 improves the situation by following permanent redirects (301 Moved Permanently) for svn update and svn info, and providing a more useful error message on temporary redirects (302 Found and 307 Temporary Redirect).

Atomic revprop changes (client and server)

Revprop changes are now handled atomically. This fixes a known race condition in the locking algorithm used by svnsync (see issue #3546). It is possible to fix the svnsync race condition even for pre-1.7 svnsync clients by installing the pre-revprop-change hook script given in comment 12 of issue #3546. (The hook script requires a 1.7 or newer server for correctness.)

Merge-Tracking Enhancements

While there are scores of bug fixes, performance improvements, and other changes to merge-tracking, the following are the major changes. See the 1.7.0 section in the CHANGES file for a complete list.

Reduced subtree mergeinfo changes

Merges no longer record mergeinfo (describing the merge) on subtrees (that have their own explicit mergeinfo), if the subtree was unaffected by the merge. This should greatly reduce the number of spurious svn:mergeinfo property changes for users who have large numbers of subtrees with explicit mergeinfo.

If a change being merged contains svn:mergeinfo modifications these will still be applied, just like any other property modifications. So if the change being merged was itself the result of another merge performed with a 1.5 or 1.6 client, excessive subtree mergeinfo changes are still possible. Best results will be achieved for new branches created and maintained exclusively with 1.7 clients.

Reintegrate merges are less restrictive

Reintegrate merges now succeed in the case where all the prior 'sync' merges were done as subtree merges, but effectively all the changes were merged from the target to the source. Reintegrate also works with shallow targets, as long as none of the excluded subtrees are affected by the merge.

Improved notification about mergeinfo changes

Merge-tracking aware merges now produce special notifications and headers when a merge records mergeinfo describing a merge or elides mergeinfo. This clearly differentiates between changes that are made due to application of a diff from the merge source and those that are simply merge-tracking 'housekeeping' changes.

Below is an example of the new output, showing notifications about application of a diff to the file lib/src/psi.c and mergeinfo changes resulting from this merge.

   $ svn merge ^/trunk -c3 --depth infinity
   --- Merging r3 into 'lib':
   U    lib/src/psi.c
   --- Recording mergeinfo for merge of r3 into '.':
    U   .
   --- Recording mergeinfo for merge of r3 into 'lib':
    G   lib
   --- Eliding mergeinfo from 'lib':
    U   lib 

Merges into mixed-revision working copies now disallowed by default

To prevent unnecessary conflicts, svn merge will now fail with an error if the merge target is a mixed-revision working copy.

A mixed-revision working copy will need to be updated with svn update before a merge can be performed into it. This restriction has always existed during merges using the --reintegrate option and it is now the default behaviour for every type of merge.

For backwards-compatibility, there is a new option called --allow-mixed-revisions which disables the check for a mixed-revision working copy, except for reintegrate merges. Using this option is not recommended. Please use svn update instead.

The mergeinfo subcommand accounts for subtree and partial merges

The svn mergeinfo subcommand now flags revisions wich are partially merged to a target with the '*' decorator. A revision may be partially merged due to non-inheritable mergeinfo on the target or because of explicit mergeinfo on some subtree of the target. The latter case is ignored by default, but may be considered by using the new --depth and -R options for svn mergeinfo.

Transitive record only merges

Merges performed with the --record-only option now apply svn:mergeinfo diffs from the merge source.

Merges into sparse directories no longer cause tree conflicts

Merges into shallow working copies used to cause tree conflicts on nodes which were affected by the merge but not present in the working copy. In 1.7, no tree conflict is flagged. Instead, non-inheritable subtree mergeinfo is created on the parents of missing nodes, so that later merges into working copies that are not sparse will pick up any missing changes for those nodes.

Server-side performance tuning

Previous releases of Subversion already supported various caching mechanism like memcached. In version 1.7, the servers will aggressively cache data in-process to maximize performance. To mitigate the network throughput as the next potential bottleneck in the chain, the data compression rate can be configured as well.

Data caching

Per default, Subversion server processes will use a 16 MB memory block to cache file and folder content. This amount is being allocated by every server process. If you want to increase the cache size, the maximum cache memory available per process can roughly be estimated as

cache limit = 0.8 * (RAM size / max. server process count) - 4 MB

Another reasonable upper limit to that in-process cache size is the size of the active data set. This is usually the size of user files in /trunk plus the size of all differing files on active branches. So, for the whole server, two or three times the sum of file sizes of all /trunks in active repositories on that server is a good indication for a performance-optimal cache size.


If one of your repositories contains a folder with more than 10,000 entries (not counting files and folders in sub-trees), you must increase the cache size.

Failure to do so may result in severe performance degradation while working on that folder. 64 MByte will be enough to handle 25,000 entries per folder. For each time that number gets doubled, the required cache size quadruples. I.e. 4 GByte will be good for about 200,000 entries per folder.

Reverting to 1.6-style caching (by setting the cache size to 0) will reduce overall performance and may cause your server process memory to grow unpredictably. However, it may help when the above limits are not feasible. 30,000 entries will result in about 64 MByte of dynamically allocated memory and about 512 MByte for 250,000 when using 1.6-style caching.

svnserve introduces a new optional --memory-cache-size / -M command line parameter to override the default cache size. Using --cache-fulltexts and --cache-txdeltas you may instruct the server what kind of data should be cached. The first should always be enabled unless data is only read once as during a svnrdump run. Text delta caching should be enabled unless your server memory is low.

For mod_dav_svn, a 10 GB cache configuration with maximum data coverage looks like this in httpd.conf

<IfModule dav_svn_module>
    SVNInMemoryCacheSize 10485760
    SVNCacheFullTexts on
    SVNCacheTextDeltas on

As a side-effect, the memory consumption becomes more predictable in many usage scenarios since there is less need to gather and pre-process data. Please note that a cache size of 0 will deactivate the new caching facilities and cause the server to fall back to 1.6 caching mechanisms.

Network data compression level

Subversion servers are often disk or network I/O limited. With the introduction of data caching, however, disk I/O can be widely eliminated and the CPU load created by data compression will become a bottleneck on fast network connections.

The default setting will allow for 10 to 15 MB/s net data throughput (5 MB to 10 MB compressed data) per client and per CPU core. On a multi-core server with a 1 Gb network connection or if clients are mainly connected with very limited bandwidth, you may want to select a higher compression rate to squeeze a little more data through the network at the expense of significantly higher server CPU loads. If the server's NIC is not a bottleneck, you may consider lowering the compression level to 1 or 2 for 100 Mb clients and to 0 (compression off) for a network with predominately 1 Gb clients.

To that end, svnserve accepts the new optional --compression or -c command line parameter. mod_dav_svn supports the feature as well but its impact is limited since over HTTP, network data compression is used only in certain cases to begin with. The optional module parameter SVNCompressionLevel controls it:

<IfModule dav_svn_module>
    SVNCompressionLevel 9

Optimizations of diff, merge and blame

The svn diff algorithm, which is at the core of diff, merge and blame, has undergone several optimizations. For large files which have a lot of identical lines at the beginning and/or the end, or files which have many lines which are unique to one side of the comparison, the speedup can be very significant.

Detecting MIME types with libmagic

Subversion 1.7 can optionally be compiled with support for libmagic to detect MIME types of binary files which are added to version control. This feature is used only for binary files for which no MIME type is found via auto-props or the mime-types-file configuration option.

Per repository authz file (mod_dav_svn)

Subversion 1.7 allows using AuthzSVNReposRelativeAccessFile (mutually exclusive with AuthzSVNAccessFile) to allow specifying a per repository access file for mod_dav_svn. This makes server installations with many repositories easier to manage. The path is relative from the conf/ subdirectory in the repository.

Changing case of file and directory names on Windows

Subversion on Windows now fully supports changing the case of file and directory names. No more special workarounds, a simple 'svn mv file.java File.java' just does the right thing.

HTTPD 2.4 Support

Subversion 1.7.5 is the first release that supports httpd 2.4. Since httpd 2.2 and httpd 2.4 are binary incompatible Subversion must be built to use one or the other. The processor/threading behaviour in httpd is controlled by the multi-processing-module or MPM. In 2.2 the MPM is fixed when httpd is built, in 2.4 the MPM can be dynamically loaded like other modules. On Unix-like systems the default MPM in 2.2 is the worker MPM and in 2.4 the event MPM (binary distributions may choose other defaults). The event MPM is incompatible with Subversion's BDB backend so mod_dav_svn will refuse to open BDB repositories, and log an error, when using the event MPM.

Known issues in the release

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

64-bit RHEL2

Building Subversion 1.7.0 and APR 1.4.5 from source on 64-bit RHEL2 with the standard compiler will produce executables that SEGV on startup. This problem is likely to affect all 64-bit x86 platforms that use gcc 4.0.x or older and is due to APR bug 51851. Workarounds include using a more recent gcc or configuring APR with --disable-nonportable-atomics.

OS X 10.7

The SQLite shipped with OS X 10.7 will produce executables that fail at runtime with the error:

svn: E200030: Could not initialize SQLite shared cache

A fix for this problem will be included in the 1.7.1 release.

JavaHL SEGV during GC

The JavaHL bindings have moved to the org.apache.subversion package with org.tigris.subversion provided as a compatibility layer. Using the compatibility package will cause the JVM to SEGV when SVNAdmin or SVNClient objects are finalized. A fix for this problem will be included in the 1.7.1 release.

APR 1.4.6

When Subversion is built with APR 1.4.6 some of the Subversion regression tests will FAIL at random due to a change in the APR hash table implementation. The APR change causes some Subversion output to appear in a different order and the testsuite will FAIL when it expects the old order; the regression tests for the Subversion bindings may also FAIL. This is a bug in the testsuite and does not indicate a failure in Subversion. A fix for the main regression tests will be included in the 1.7.4 release.

prop_tests.py 35 FAIL

The regression tests may report a fail for prop_tests.py 35:

FAIL:  prop_tests.py 35: pg of large text properties redirects properly

This happens when the user running the regression tests has a configuration directory (typically $HOME/.subversion) that causes the Subversion 1.7 command line client to fail. A fix for this problem has been included in the 1.7.7 release.

mod_dontdothat Compile Error

Building Subversion 1.7.6 without Apache installed will still attempt to build the Apache module mod_dontodothat and the compilation will fail due to missing header files such as httpd.h. To work around this without installing Apache edit build-outputs.mk and change the two line mod_dontdothat.la rule at lines 454 and 455 to the single line:


1.7.7 restored the build and installation of mod_dontdothat to the same behavior as it was prior to 1.7.6.

mod_dav_svn Maps Requests to Local Filesystem

Prior to Subversion 1.7.12 all previous versions of mod_dav_svn would allow Apache httpd to map requests handled by mod_dav_svn to the local file system. When this happened httpd would believe that it was serving a file or directory located at the path that comprises the URI path appended to the DocumentRoot of the server but ending at the first path component that does not actually exist on the local disk. For example if your DocumentRoot was /var/www and you were accessing /svn/repo/README and /var/www/svn did not exist then httpd would believe it was serving /var/www/svn, but if /var/www/svn existed while /var/www/svn/repo did not then it would believe it was serving /var/www/svn/repo. This had several undesired side effects.

  • <Directory> blocks could match requests being served by mod_dav_svn. This would allow directives applied in these configuration blocks (most notably access control directives) to be applied.
  • When using Apache httpd 2.4.x and mod_dir, if a file from the DirectoryIndex directive existed at the path Apache httpd believed it was serving then the request would be rewritten to access that file, which may or may not exist. If the path was the SVNParentPath then SVN would try to access a repository with the name of the DirectoryIndex file that was found.
  • When using the %f variable in your log directives you would log the path constructed as described above. This was confusing since it was not the content that was actually served.

Starting with Subversion 1.7.12 the requests being served by mod_dav_svn will not be mapped to the local file system and when logging with the %f variable you will see a "-" logged. <Directory> blocks will no longer apply to such requests. Subversion 1.7.14 changed this further and the filename for the request will now be set as svn:/path/to/repo/path/in/repo (e.g. if your repo is at /var/svn/repo and the request is accessing /trunk/myfile in the repo then the filename for the request will be set to svn:/var/svn/repo/trunk/myfile. Note that the svn: prefix will prevent the filename from matching an actual path on disk since it isn't a valid path and as such <Directory> blocks will still not apply.

WARNING:Therefore, if you were using <Directory> blocks to restrict access to paths served by mod_dav_svn you will need to adjust your configuration. Since the local filesystem path was not complete this never would have been very useful for path based authorization, but it could be misused for simple things like blocking an IP. These directives must be moved inside the appropriate <Location> blocks.

WARNING:This change may cause checksum errors with misconfigured httpd servers. Since 1.7.14 the filename in the request record now includes the filename in the repository, there have been cases of mod_mime interfering with Subversion. Users will see a svn: E200014: Checksum mismatch error when working with files that end in .gz if a configuration setting like AddEncoding x-gzip .gz is in their configuration file and applies to the locations that Subversion is being served from. This happens because the setting now matches on the Subversion traffic and sets the Content-Encoding header to specify that the file has been gziped for transmport without changing the file content. Since the Subversion client supports gzip content-encoding it decompresses the file and ends up with the decompressed file which does not match the checksum of the file it expected. It is possible that this change may cause other filters to match Subversion requests that would not have in the past and trigger other similar errors with other httpd configurations.

Dependency, license and distribution changes

Subversion 1.7 marks the first official feature release as part of the Apache Software Foundation. A few bits of minutiae have changed as a result.

Subversion Dependency Distribution

Previous releases of Subversion shipped with companion artifacts which included a number of Subversion dependencies. In the past, these dependencies were hard to find and build, and not often installed on the target platform. Today, this is no longer a problem, so we have discontinued shipping the companion dependency tarballs. If you still want to get some of the required Subversion dependencies before building, you can run the get-deps.sh script in the root of the unpacked archive.

License changed to Apache License, version 2

Since its inception, Subversion has a used a "modified Apache license". The migration of the project to the Apache Software Foundation provided an opprotunity to also change the license to the standard Apache License, version 2. Additionally, the copyright to the collective work is now owned by the ASF. While this has very little practical effect, it does mean consumers have one less license to worry about when deploying Subversion.

Download location changes

The download location for Subversion source tarballs and other release artifacts are now hosted by the Apache Software Foundation. This includes the official distribution location, as well as archives of all previous Subversion releases. Of course, other locations are welcome to continue to host Subversion distribution artifacts, but the Apache download sites are now the canonical source for Subversion releases.

No longer shipping contrib/

Since the early days of Subversion development, the Subversion repository has hosted a section for various other tools and scripts related to Subversion. As Subversion has become more popular, the need to host these tools in the main repository has decreased to the point where we encourage tool authors to host their contributions at one of a number of external hosting platforms. For this reason, and the potentially uncertain nature of some of the licenses on these scripts, we have stopped shipping the contrib/ directory in the release tarballs. For the time being, these scripts remain available via the main repository.

Subversion 1.5.x series no longer supported

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