This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
The Best of Subversion 1.7
There are a few cool features and enhancements scheduled for the next major release of Subversion (1.7). I’d like to quickly review some of them and explain the advantages and what it means for Subversion users. We can expect to see Subversion 1.7 in the “first half of this year”, according to Hyrum K. Wright, Director of Open Source, WANDisco. As with all open source software, it will be done when it’s done. Some of the cool new features are:
- New protocol for Subversion (HTTPv2)
- New working copy library (libsvn_wc)
- Early obliterate support
- Augmented diff representation (svn patch)
Early in this history of Subversion, the decision was made to base Subversion on Apache + WebDAV/DeltaV. There were a number of advantages to this including zillions of Auth options via Apache, standardized encryption (SSL), excellent logging, ability to go through corporate firewalls, and caching with intermediate proxies. This turned out to be limiting in some respects, including DeltaV being complex and inefficient. The overall performance of Subversion suffered as a result.
The Subversion folks have decided to write a new protocol (HTTP v2), which will presumably maintain the positive side effects of using WebDAV/DeltaV while offering more speed and efficiency. The main advantages are that it will reduce the number of round trips per operation (which is useful on high-latency links), it’ll be easier for future developers to extend, and it allows better caching with web proxies. I’m sure all Subversion users will be happy with this news, and we can all look forward to a much faster Subversion. Check out the Subversion issue tracker for more details.
New working copy library
Another performance enhancement planned is a new working copy library. Most Subversion users will be familiar with those “.svn” directories which are stored on the client side (your workstation / developer box). Subversion maintains one of these directories per directory in your working copy to store meta data about your repository.
The main problem with this model is that Subversion relies on the existence of cached, pristine files in “.svn/text-base/”, meaning that it’s more suited to storing small text files (your source code). Of course the usage patterns of Subverison users has changed substantially, and at Codesion we now see many customers storing a wide range of binaries and digital assets beyond source code, such as videos, business/technical documents, Photoshop files, etc. Of course the obvious answer to this problem is to buy a larger disk, but thats not ideal of course.
Work is underway for 1.7 which will see a new working copy library with centralized metadata, so instead of using the filename as a key to reference a file, it will use a generated index key and avoid case sensitive file name issues we see often under NTFS. It will be based on SQLite DB for storage, store properties in the DB, introduce a new concept of a workqueue instead of the current log files, more friendly API for GUI developers, faster locking, ability to remove deleted directories, shared text-bases which reduces disk usage for working copies with shared branches, and aims to be backwards compatible with the current libsvn_wc. Check out the Subversion issue tracker for more details.
This one is pretty simple. Currently in Subversion there is no way to really delete a file or directory: the delete operation merely flags a file as ‘deleted’, but it’s never actually removed from disk on the server side. This is beneficial in that you can rollback to any point in time in your project history before a file was deleted, and not lose any dependencies or history that other files may have with that deleted file.
However there is a case for an “obliterate” function which completed annihilates a file or directory. Say for example you accidentally committed a massive file, or wish to hide private data that was committed by mistake, or just remove one file in a revision. Having this ability allows you to reduce the disk storage requirement on the server side and maintain privacy in the unfortunate even you commit something you shouldn’t have, or you just simply made a mistake. Julian Foad, Senior Subversion Committer, says there will be an audit trail of some sort which will log who, what, when for each obliteration, and sysadmins will be able to add authorization via hooks. Initially there will only be support to remove the youngest revision of a file, but this will be extended. Of course we’ll be enabling access to this feature via our interface, so there will be no need for our customers to write hooks.
Augmented diff representation (svn patch)
Most Subversion users will be familiar with ‘svn merge’, which is a very powerful and core tool in Subversion used to keep your trunk in synch with a branch, or more generally to merge changes from one tree to another. This requires that both trees be stored in Subversion. The Subversion maintainers are planning to introduce ‘svn patch’ which would allow you to merge a patch file, much like the output from Linux ‘diff’, to your Subversion working copy, without the need for the source of the patch to exist in another Subversion branch. There isn’t too much published about this feature on the Subversion site, but one would assume you’d be able to do something like this eventually,
svn patch < diff.txt
in your working copy, or
svn diff http://official.svn.org/trunk | svn patch .
to apply changes from an entirely separate repository. If this feature is pushed far enough it might provide a kind of ‘lite’ implementation of what’s core in distributed SCMs like Git.
We’re all looking forward to Subversion 1.7!