Top New Features in Subversion 1.7: WC-NG & Pristines

Subversion 1.7 is a major update for the Subversion community; not only will it deliver long-awaited client-side performance improvements and new client tools, but improvements to the working copy metadata system will pave the way for even more innovations in future releases of Subversion. Some of the key updates are:

  • WC-NG – a complete rewrite of the working copy metadata system.
  • Pristines – a new way of storing text-bases in 1.7.
  • Merge-tracking enhancements – over 40 improvements to merge tracking.

One of the major improvements in Subversion 1.7, is a complete rewrite of the working copy (WC) metadata management system; one of the oldest parts of Apache Subversion. Subversion inherited the blueprint for handling its working copy metadata from CVS, but there are some built-in problems with this scheme. Some examples include:

  • A search for all files containing ‘test’ can potentially turn up Subversion text-base files, alongside working files.

  • When deleting a directory in Subversion, the files are removed, but the directory and the sub-directories remain on disk until the change is committed. This is because Subversion needs to hold onto the metadata contained within the directory.

  • Subversion failed when developers on case-insensitive platforms attempted to rename a file, just by altering the letter casing.

Although such problems are only minor, together these fixes add up to a much more robust metadata storage system.

Subversion 1.7 users will notice an immediate performance improvement, as WC-NG centralizes the working copy’s administrative metadata in a single database. Previously, Subversion maintained one .svn directory per directory in the working copy, to store metadata about a repository. This forced many Subversion operations to walk the entire directory tree, to gather all the necessary information about the working copy. All the metadata for the whole working copy is now stored in a single datastore in the root of the working copy, making it easier to manage, and easier to ignore, when required.

Over the years, the original WC library had grown so complex, that introducing bug fixes and improvements was becoming an uphill struggle; this redesign clears the way to incorporate new features in future releases. One of the features WC-NG enables for future releases, is stashing. This feature would allow Subversion users to ‘stash’ changes they were working on – allowing them to focus on urgent bug fixes, for example – and then recover the changes from the stash after the urgent commit has been completed. Once implemented, this feature could even be extended in Subversion: applying subsets, multiple stashes, and management of those changes, are all capabilities that could be added to the stashing functionality in Subversion.

Subversion keeps a record of the unmodified contents of all files in the working copy. Previously, these have been called ‘text-bases’ but in Subversion 1.7 they have been renamed ‘pristines’ and have been moved to the same datastore as the working copy metadata, where they are stored by checksum in a sharded format. Several space-saving mechanisms have also been introduced:

  • files in the working copy with the same pristine content, share references to the pristine store.
  • svn cleanup can be used to remove pristines that are no longer required by the current state of the working copy.
  • In future releases of Subversion, unreferenced pristines should be removed automatically.

This new storage method fixes a problem encountered when a user stored files with the same name, but with different capitalization, in the same directory. Developers on case insensitive file systems (such as Windows) were unable to checkout repositories containing such files – this no longer causes problems with Subversion 1.7. Instead of using the filename as a key to reference the file, WC-NG will use a generated index key to avoid case-sensitive file name issues.

To reduce the number of false svn:mergeinfo property changes for users who have a large number of subtrees with explicit mergeinfo, Subversion 1.7 no longer records mergeinfo on subtrees, when the subtree is unaffected by the merge. False svn:mergeinfo property changes can still occur if the change being merged is the result of another merge performed with a 1.5 or 1.6 client, as changes being merged that contain svn:mergeinfo modifications will still be applied. To get the most out of this new feature, Subversion users should create and maintain branches exclusively with 1.7 clients. On top of limiting the recording of subtree mergeinfo, Subversion 1.7 introduces more user-facing changes to merge:

  • For merge-aware tracking merges, special notifications and headers are produced when a merge records merge-info describing a merge, or omits mergeinfo.

  • Merges into mixed-revision working copies are now disallowed by default, to prevent unnecessary conflicts. A mixed-revision working copy must be updated with svn update, before a merge can be performed into it.

  • The svn mergeinfo subcommand flags revisions which are partially merged to a target.

  • Merges into shallow working copies no longer causes tree conflicts on nodes affected by the merge, but not present in the working copy.

In our second post on Subversion 1.7, we’ll look at some other key updates in this major release, including:

  • HTTPv2 – a new HTTP protocol variant designed to enhance performance between Subversion clients and the server.

  • New in-memory caching system for FSFS repository backends

  • Network compression – a protocol for avoiding CPU bottlenecks on the compression side.

  • svnrdump – a new client tool that provides the same functionality as svnadmin dump and svnadmin load, but on remote repositories.

Like any successful open source project, Subversion has always relied on active participation and feedback from its user community, but 1.7’s emphasis on client-side performance and new client tools, mean this is more important than ever. Provide your feedback, get advice on the latest features, and connect with other 1.7 users, at http://www.svnforum.org/forums/56-Apache-Subversion-1.7-Support

To help users on the path to 1.7, we’ll be shipping both Subversion 1.6.17 and 1.7 in our free, open ALM platform, uberSVN. Users will be able to easily switch between the two releases, through a unique new ‘toggle’ feature in uberSVN’s configuration settings. This gives users the option of upgrading to 1.7 to take advantage of the new features, but with the safety-net of downgrading to 1.6.17 if required. But, if you need that extra support, we will also be offering three migration packs as part of our professional support services, designed for organisations moving from Subversion 1.6 to 1.7, and for those looking to make the leap from alternate solutions (ClearCase, PVCS, StarTeam, MKS, CVS) to Subversion 1.7. To learn more about WANdisco’s complete range of Subversion support options visit: http://www.wandisco.com/subversion/support