Subversion 1.2 Release Notes

What's New in Subversion 1.2

Subversion 1.2 is a superset of all previous Subversion releases. Anything in 1.0.x and 1.1.x is also in 1.2, but 1.2 contains features and bugfixes not present in any earlier release. The new features will eventually be documented in a 1.2 version of the free Subversion book, see


Subversion 1.2 is available as source code in three formats:

For binary packages, please see the binary package list. Note that binary packages usually come out about a week after the corresponding source release. The package maintainers are volunteers, so please don't harass them — they know when a new source release has come out, and they work as fast as they can to make binaries available.

For other Subversion releases, see this folder.

Compatibility Concerns

Older clients and servers interoperate transparently with 1.2 servers and clients. Of course, some of the new 1.2 features may not be available unless both client and server are the latest version. There is no need to upgrade your repositories; Subversion 1.2 can read repositories created by earlier versions. To upgrade an existing installation, just install the newest libraries and binaries on top of the older ones. (WARNING: if you're using Berkeley DB repositories, installing a new binary distribution of Subversion may force you to upgrade Berkeley DB as well, see Unexpected Berkeley DB Upgrades below.)

Subversion 1.2 maintains API/ABI compatibility with earlier releases, by only adding new functions. A program written to the 1.0 or 1.1 API can both compile and run using 1.2 libraries. However, a program written for 1.2 cannot necessarily compile or run against older libraries.

Command Line Output Changes

Although the Subversion developers try hard to keep output from the command line programs compatible between releases, new information sometimes has to be added. This might break scripts that rely on the exact format of the output. In 1.2, the following changes have been made to the output:

  • For svn update, the paths have been shifted two columns to the right, thus they start in column five. Column three now contains a B when a lock was broken or stolen.

  • svn status adds information about locks in the sixth column. Note that this column was previously unused, so the old information is still in the same positions as before.

  • Several lines were added to the svn info output, containing lock information.

Unexpected Berkeley DB Upgrades

This is not actually related to the Subversion 1.2 release, but it may affect you if you upgrade to 1.2 via a package distribution system.

A lot of operating systems now ship Berkeley DB 4.3. Sometimes the system Berkeley DB libraries can be unintentionally upgraded to 4.3 as part of some other change pulled down via an OS package delivery mechanism — for example, upgrading one's Subversion package. If this happens to you, you will need to upgrade existing BerkeleyDB-based repositories to 4.3.

In particular, the latest Windows binary distributions [link obsolete as of June 27, 2021] of svn 1.2 (from Branko Cibej) now use Berkeley DB 4.3. Please be warned!

Known Bugs

Subversion 1.2.3 fixes several bugs in 1.2.1 and 1.2.0 (1.2.2 was a placeholder release and was never officially blessed). See the 1.2.3 announcement and 1.2.1 announcement for details about those releases.

As bugs are fixed in /trunk (the future svn 1.3), they will continue to be backported to the 1.2 line for future 1.2.x releases. Here is the list of open issues.

New Features

File Locking (requires new client and server)

"Locking" is a long-requested feature, often known in other systems as "reserved checkouts". While Subversion is still primarily a copy-modify-merge system focused on parallel development, there is widespread acknowledgement that not all files are easily mergeable — binary files in particular, such as artwork, compressed files, proprietary binary formats, or any other non-line-based data.

The goal of the new locking feature is twofold. First, provide a means to force serialized write-access to a file. Second, provide a communication mechanism to prevent users from wasting time on unmergable changes.

This feature is now documented in the nightly build of the svn 1.2 book, available here. (Note that this link is temporary; when the 1.2 book is finished, the URL may change.)

Warning: if locks are in use in a repository, then a pre-1.2 libsvn_fs library won't see or enforce them. This is really only relevant to teams of users all accessing the repository via file://. For example, an svn 1.2 client might lock a file, but a statically-linked svn 1.1 or 1.0 client (accessing via file://) will unknowingly ignore the lock. The workaround, of course, is to set up a real server process — thereby guaranteeing that only libsvn_fs 1.2 ever accesses the repository.

Full DAV autoversioning (mod_dav_svn feature)

Autoversioning is a feature whereby generic WebDAV clients can write to a DeltaV server (like mod_dav_svn), and the server performs commits silently in the background. This means that if you use Apache httpd as your Subversion server, then most modern operating systems can mount the repository as a network share, and non-technical users get "transparent" versioning for free. (Of course, technical users can still use Subversion clients to examine repository history.)

Prior to Subversion 1.2, mod_dav_svn had only partial interoperability with generic DAV clients. Appendix C in the Subversion 1.1 book documented the trials and tribulations of this exercise. At most, one could use a DAV client to drag files into a mounted repository, but the files couldn't be edited directly from the network share. Some clients even refused to mount the Subversion repository.

Now that the repository supports locking, generic DAV clients can happily issue http LOCK and UNLOCK requests, and files can be opened/edited directly from the share. As far as we can tell, mod_dav_svn is now fully implementing the 'autoversioning' feature according to the RFC2518bis specification.

In informal tests, we've had success reading and writing to Subversion repositories via Windows Web Folders, OS X Finder, Gnome Nautilus, KDE Konqueror, and other DAV clients.

To activate autoversioning, simply set SVNAutoversioning on in your httpd.conf's Subversion Location block. Be warned, however, that making your repository writable by generic DAV clients may result in lots of small commits. A DAV client may seem to be saving a file, but is in fact performing several write operations under the hood, each resulting in a separate commit. Experiences may vary.

This feature is now documented in the nightly build of the svn 1.2 book, available here. (Note that this link is temporary; when the 1.2 book is finished, the URL may change.)

New subcommand switches:

svn log --limit N
Display only N revisions, then stop. (Note: a 1.2 server isn't required for this, but strongly recommended. A pre-1.2 server will still attempt to deliver all revisions over the network, even though the 1.2 client isn't displaying them.)
svn info --revision (-r)
Show detailed info on older versions of items.
svn list --xml
Output listing in XML.
svn propset --force
Allow unusual propsets, such as svn:eol-style on a file with a binary svn:mime-type..
svn diff --force
Show differences even on files with binary mime-types.
svn checkout/update/status/export --ignore-externals
Don't process any svn:externals during operation.
svn export --non-recursive (-N)
Don't export subdirectories.
svnversion --help
Show help on svnversion.
svnlook diff --no-diff-added
Don't show added files in the diffs. Companion to --no-diff-deleted.
svnlook propget/proplist --revprop
Examine revision props, instead of normal versioned properties.
svnadmin load --use-pre-commit-hook / --use-post-commit-hook
Invoke pre-commit or post-commit hooks when loading a dumpfile into a repository.

Enhancements and Bugfixes

Faster access to old revisions due to xdelta compression (server)

The repository is now using the xdelta differencing algorithm (instead of vdelta) to store compressed difference data. When you upgrade to Subversion 1.2, existing repositories will continue to work fine; the revision history will simply be a mixture of xdelta and vdelta differences.

The xdelta algorithm is much faster at reconstructing older files, and thus there's motivation to dump and reload your existing repository. If you do this, you forcibly re-compress all repository history using the xdelta algorithm, resulting in a noticeable speedup in operations that ask the server to reconstruct older data: svn blame, svn checkout, svn update, svn diff, svn merge, and so on. Even dumping the repository will be faster.

Note: There's a small trade off between speed and disk space. If you choose to re-deltify your whole repository using xdelta, its size will grow by roughly 10 to 15 percent.

FSFS repositories are now the default (server)

After the tremendous success of FSFS repositories since the 1.1 release, we've changed the svnadmin create command to create FSFS repositories by default. This should provide a friendlier "out of box" experience for new users.

Note: Berkeley DB repositories are not being phased out or deprecated in any way. The reliability problems we've seen lie not in Berkeley DB itself, but in the unique way Subversion uses Berkeley DB. Cooperative work is currently underway (with Sleepycat engineers) to address these issues. Berkeley DB repositories are still older and better-tested than FSFS repositories in terms of scalability; the project still recommends you read about the two back-ends in the book and make an informed choice.

Cached passwords are encrypted on Windows (Windows client)

On Windows 2000 and later, the command-line client encrypts the cached passwords used for authenticating to a remote Subversion server (via the http:// or svn:// protocols). Existing, unencrypted cached passwords are automatically encrypted the first time they are used.

This feature does not extend to stored passphrases for client SSL certificates.

Note: The client uses the standard Windows Cryptography services to encrypt and decrypt the password. Among other things, this means that the encryption key is managed by Windows and can only be accessed by the user account that owns it. If an administrator forcibly resets the account password, the encryption key (and consequently the cached passwords) will no longer be accessible (by the way, the same holds for the contents of NTFS-encrypted files). The Subversion client will detect this and proceed as if the password were not known; that is, it will prompt the user for the password when necessary.


More than 50 new bugs fixed. See the CHANGES file for details.

Developer Changes

The svn_ra.h API has now been "flattened", essentially imitating the same way the svn_fs.h API hides multiple implementations. Instead of making calls into an RA vtable (ra->do_foo()), all RA functions are now usable directly in the form svn_ra_do_foo(). This also has the nice side-effect of making svn_ra.h available via SWIG.

As with svn 1.1, a number of new 1.2 functions have been introduced, and older versions are now marked deprecated (and will be removed in Subversion 2.0). See the CHANGES file for details. The full list of new 1.2 APIs is here.

There has been extensive work on the Python, Perl, and JavaHL bindings. We also now have a preliminary set of Ruby bindings.

Deprecation of 1.0.x Series

The Subversion 1.0.x line is no longer supported. This doesn't mean that your 1.0 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.0.x versions, and will not make any more 1.0.x bugfix releases (except perhaps for a critical security or data-loss bug.)