Subversion versus Perforce

Back in 2000, CollabNet Inc initiated a new open source SCM (Software Configuration Management) project called Subversion. Its goal was to improve on CVS (Concurrent Versions System), the de facto standard in the open source world and still hugely popular.

One of the issues with CVS was lack of support for atomic commits. Without atomic commits, a failure midway through checking in a set of changes can leave the repository in an inconsistent state. Subversion addresses this and is generally more flexible than CVS. It also works better with binary files, a facet of project management that is becoming increasingly important, particularly in web projects with their many graphical files. Subversion usage is growing fast, and while there are no doubt more CVS repositories out there thanks to its long history, Subversion is often chosen for new projects.

Subversion was born in the open source movement, where use of proprietary systems such as Rational ClearCase is not an option. In addition, there is considerable dissatisfaction with some of the leading commercial products. Heavyweight systems like ClearCase carry an administrative burden, while over in the Microsoft world, Visual SourceSafe is little loved by its users.

SourceSafe is entirely unsuitable for remote users, and appears more prone to corrupting its repositories than rival systems. The main SourceSafe benefit is integration with Visual Studio and the fact that it comes in the box. There is a steady stream of users fleeing SourceSafe towards other systems, one of which is now Microsoft’s own replacement, Team System.

A shining star among proprietary SCM systems is Perforce. Although entirely closed-source, Perforce shares the lean, modular approach favoured by Subversion and CVS. The Perforce server runs as a daemon or Windows service, and runs its own customized version of BerkeleyDB with few dependencies or administrative requirements. It is cross-platform on both client and server, and all its features are accessible through command-line tools, with GUI clients also available for the most popular operating systems.

The company claims to be at least equal to the open source community in responding to developer needs. According to Dave Robertson, Perforce's Director of European operations, “If anyone comes to us with a new platform, then we can usually get a command-line version of that port available within a couple of weeks.”

Subversion essentials

The heart of subversion is a repository, based on either a BerkeleyDB database or built directly on the file system. The preference is debatable; a proven database management system feels safer, but BerkeleyDB-based repositories have been known to lock up and require a restart of the daemon; the file system performs better and does not suffer from lock-ups. What is confusing is that Subversion repositories can be accessed in several different ways.

Svnserve is a Subversion daemon that serves clients over any TCP/IP network; or clients can access the file system directly either locally or through file sharing; or you can have an svnserve process triggered by an SSH client; or you can use Apache 2 with a DAV module. This last is the most scaleable and flexible, but a little more complex to configure.

Subversion clients include the command-line svn, and various IDE plug-ins and GUIs. For example, the Subclipse project gives Eclipse users IDE support. On Windows, TortoiseSVN is a GUI client nicely integrated with Windows explorer, complete with icons showing the status of your working files.

Subversion is great for offline working, because it keeps a local copy of the latest server version. You can see what you have changed without contacting the server. Advanced users can create hook scripts, similar to triggers, written in any available language. These fire in response to repository events.