Subversion 1.4 Release Notes

Working Copy and Repository Format Changes ¶

Due to certain improvements and bugfixes made to the working copy library, the version number of the working copy format has been incremented. This means that Subversion clients earlier than 1.4 will not be able to work with working copies produced by Subversion 1.4. Similarly, the repository format has changed as well, meaning that pre-1.4 Subversion tools that normally access a repository directly (e.g. svnserve, mod_dav_svn, svnadmin) won't be able to read a repository originally created by Subversion 1.4.

WARNING: if a Subversion 1.4 client encounters a pre-1.4 working copy, it will automatically upgrade the working copy format as soon as it touches it, making it unreadable by older Subversion clients. If you are using several versions of Subversion on your machine, you need to be careful about which version you use in which working copy, to avoid accidentally upgrading the working copy format. This "auto upgrade" feature, however, does not occur with the new repository format.

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.4, the following changes have been made to the output:

• Conflict markers in files now match the file's defined eol-style.

svnsync (some features require a 1.4 server) ¶

A new tool — svnsync — is now installed as part of the standard distribution. This tool provides the ability to replicate history from one repository to another. The replication can happen all at once, or can be done incrementally through repeated 'sync' operations. Because the tool uses the abstract network (RA) API, the source and destination repositories can be either local, remote, or any combination thereof.

Compatibility note: in order to "push" information into a destination repository, any version of the server will suffice. The pushing is done through ordinary network commits. To "pull" history from the source repository, however, requires a 1.4 (or later) server.

Usage of this tool will be documented in the Subversion book soon, but for now, running svnsync help should suffice; the number of subcommands is very small, and the help system documents them all.

Working copy performance improvements (client) ¶

The way in which the Subversion client manages your working copy has undergone radical changes. The .svn/entries file is no longer XML, and the client has become smarter about the way it manages and stores property metadata.

As a result, there are substantial performance improvements. The new working copy format allows the client to more quickly search a working copy, detect file modifications, manage property metadata, and deal with large files. The overall disk footprint is smaller as well, with fewer inodes being used. Additionally, a number of long standing bugs related to merging and copying have been fixed.

WARNING: A Subversion 1.4 client will upgrade older working copies to the new format WITHOUT WARNING, rendering them unreadable by older Subersion clients. See the section above, titled 'Working Copy Format Changes'.

BerkeleyDB 4.4 and auto-recovery (server) ¶

A common problem with previous versions of Subversion is that crashed server processes could leave BerkeleyDB-based repositories in an unusable "wedged" state, requiring administrators to manually intervene and bring back online. (Note: this is not due to bugs in BerkeleyDB, but due to the unorthodox way in which Subversion uses it!)

Subversion 1.4 can now be compiled against BerkeleyDB 4.4, which has a new "auto-recovery" feature. If a Subversion server process crashes and leaves the repository in an inconsistent state, the next process which attempts to access the repository will notice the problem, grab exclusive control of the repository, and automatically recover it. In theory (and in our testing), this new feature makes BerkeleyDB-based repositories just as wedge-proof as FSFS repositories.

WARNING: While upgrading to a new version of Berkeley DB will not require you to dump and reload your repository, you will still need to follow the Berkeley DB upgrade regimen to ensure that your repository is accessible by the new version of those libraries. Please see the Upgrading from previous versions of Berkeley DB chapter of the Berkeley DB Upgrade Guide for instructions on upgrading Berkeley DB environments.

Binary Delta Encoding Improvements (client and server) ¶

Subversion uses the xdelta algorithm to compute differences between strings of bytes. The output of this algorithm is stored in a custom format called 'svndiff'. svndiff data is what's stored in the repository to represent the difference between successive versions of files, and svndiff data is also transmitted over the wire between client and server (e.g. during updates and commits.)

In Subversion 1.4, the svndiff format has been improved to use much less disk space — up to 50% less on plain text files in some cases. Thus, if you choose to dump and reload your repository, the new repository should be noticeably smaller on disk. (Make sure to svnadmin create the new repository using svnadmin 1.4.) Additionally, if a client and server are both version 1.4 , then network traffic becomes smaller and faster.

WARNING: A repository created by svnadmin 1.4 will not be readable by earlier Subversion libraries or tools. However, in order to experience the smaller data format, you'll have to dump and reload your data. If you don't recreate your repository with svnadmin 1.4, it will continue writing data in the older, larger format, and will still be readable by older Subversion tools.

New subcommand switches ¶

This release of Subversion adds a few new switches and options to the command line client. These are:

svn blame --force

Displays the output of blame, even if the file is binary.

svn merge/blame -x

Merge and blame commands can now pass options to an external diff3 program.

svn diff/merge -c/--change

You can now simply write -c N to view or merge a single revision, instead of the cumbersome -r N-1:N.

svn diff --summarize

Prints only the list of changed files, in the output format of 'svn status'. This lets you retrieve summaries of changes directly from a repository, whereas 'svn status' operates only on the local changes of your working copy.

svn diff -x [-u | -b | -w | --ignore-eol-style]

The diff engine internal to Subversion can now ignore whitespace and eol-style when computing the diff.

svnserve as native Windows service (server) ¶

The svnserve server can now be run as a Windows service. This allows svnserve to start automatically, at system boot time, without having a user logged in and without the need for an external service 'wrapper' program. See notes/windows-service.txt for information on setting up svnserve as a Windows service.

OS X Keychain support (client) ¶

On OS X, the svn client now caches passwords in Keychain, rather than in ~/.subversion/auth/.

API improvements (client and server) ¶

If you develop a 3rd-party client application that uses Subversion APIs, you may want to take notice of some new APIs:

• The RA replay API, used by svnsync, lets you retrieve all the data associated with a set of revisions in a single operation.
• Many APIs have been revised to newer versions.

Other bugfixes (client and server) ¶

The usual slew of heretofore-unreleased bugfixes, more than 40 overall. See the CHANGES file for full details.