Original URL: https://www.theregister.com/2006/03/23/subversion_perforce/
Subversion versus Perforce
Popular source code management tools go head to head
Posted in Software, 23rd March 2006 07:02 GMT
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.
Perforce essentials
Perforce always installs as a server daemon and deployment is straightforward. Although it uses a customized BerkeleyDB, Robertson assures us that it does not suffer from lock-ups. In addition, Perforce offers a generous range of command-line tools, GUI clients, and IDE plug-ins.
You can integrate Perforce with Apache through a module called WebKeeper - allowing browser access to repositories but with limited features - or use a standalone Perforce web server called P4Web, which is more complete. Windows users get P4V, an excellent GUI client which improves on the older P4Win.
Perforce is keen to include users who are not necessarily programmers, and to promote this the company has plug-ins for applications including Microsoft Office, Adobe Photoshop, and Adobe Dreamweaver through a driver that emulates FTP. You can also access Perforce repositories through ODBC, or use the reporting tool P4Report.
A key concept in Perforce is the Changelist, which is a set of changes made to the repository at a particular time. By contrast, Subversion changesets have to be derived by comparing revisions. As with Subversion, commits are atomic. Triggers are supported, and using these is the only way to configure Perforce for external authentication, using an LDAP server or Windows Active Directory. This is one aspect of Perforce which is not as seamless as it should be. Perforce is modular. This Windows installer shows the essential modules for both client and server.
To lock or not to lock
Old-style source control works on the basis that only one person at a time can modify a file. Lock the file, edit, then check-in and release the lock. This is viable for small teams, though aggravating when someone has locked the file you want to edit. The model is unsuitable for substantial open-source projects.
Subversion therefore adopts a liberal approach. Your working files are always writable, and anyone can submit changes. If you submit changes to a file that has changed since you last updated it from the repository, the two versions are merged, either automatically, or with human intervention when that is not possible. The outcome is smoother team working, at the expense of an occasionally difficult merge.
Another possibility is to give most users read-only access to the repository. In this case, changes are submitted to project administrators in the form of patches. The admins have the task of merging the patches after checking their contents. This is a common model for open-source, and one which both Subversion and Perforce support through diff commands, letting you create patch files.
Perforce falls in between old-style locking and Subversion’s liberalism. Perforce marks working files read-only unless you check them out for edit. Multiple users can check-out the same file, but will be warned. You can easily find out who else is editing the file. By contrast, with Subversion there is normally no way to tell; all files are always checked out for edit.
Early versions of Subversion did not support locking at all, but this is no longer the case. You can now lock files, query files to see who has locked them, and even mark files as requiring locks before edits. This makes sense for binary files where merging is impossible. So Subversion now supports the locking model, though liberalism remains in that any user can break a lock on request. It’s also true that Perforce fully supports parallel working, though unlike Subversion it does not positively encourage it.
The Visual Studio dilemma Visual Studio is designed to work with third-party source code management systems through an API called SCCI (Source Code Control Interface). Perforce has a mature SCCI provider, but Subversion does not.
There are several projects under way to meet this need, including Anhksvn and PushOk, but in some respects the Subversion model is not a good fit with SCCI. Developers fall into two camps here. Some are happy to abandon IDE integration and use the excellent TortoiseSVN to work directly with the file system, while others are waiting for better integration.
There is particular hassle with Subversion when used with ASP.NET and Visual Studio 2003. Visual Studio does not like directory names which begin with a dot, used by Subversion for its local repositories. There are workarounds, but it is a nuisance; the real solution is to upgrade to Visual Studio 2005. Score one for Perforce if you like the IDE approach, especially as the “check out to edit” approach in Perforce is more what SCCI expects.
Another factor is the arrival of Microsoft’s Team System. More than simply a replacement for SourceSafe, Team System incorporates testing, project management, build management, software modeling and more. A snag with Team System is that source code management is the one thing that can’t easily be replaced by a third-party equivalent, because the whole system rests on the Team Foundation Server repository.
“It would require any SCM system to behave exactly like Team System behaves. That would disadvantage us by adding additional layers of overhead,” says Robertson.
Unlike SourceSafe, Team System is designed for the internet era, but it is nevertheless a heavyweight system which lacks the lean and mean appeal of Subversion or Perforce; it is also brand new and therefore unproven. Microsoft platform developers have to weigh the attractions of Team System and its deep Visual Studio integration against the flexibility and high performance of these alternatives.
One bonus for Perforce users is its licensing model. “Rather than pull out different editions for different prices for different levels of user, we offer a single license and you get absolutely everything. We price on a per named user basis.” How sensible, and a refreshing contrast to role-based licensing from the likes of Microsoft and Borland, though in fairness Perforce is more narrow in focus than suites like Team System.
Perforce vs Subversion
There are no losers in this contest. These are two strong SCM systems, and preferences are to some extent a matter of taste. They also have much in common: lightweight, high performance, modular, cross-platform, work well with binary files, have command-line as well as GUI tools, and both founded on the principle of a single centralized repository with cheap copying and strong branch management.
Still, there are important differences. Subversion is open source and free, though commercial support is possible from CollabNet or others. Perforce is proprietary, though free for up to two users or for qualifying open source development; all credit to the company for its universal per-user license.
Perforce is easier to deploy, wrapping all its server functions into a single daemon, whereas Subversion relies on Apache 2 for certain features including WebDav and the most flexible access control. This does enable Subversion to take advantage of Apache’s authentication options, whereas Perforce is tricky to configure for external authentication.
Perforce has a wider range of plug-ins for IDEs than Subversion, including other content producers such as Microsoft Office, though many developers are happy to work through the file system, and Subversion’s Windows users get the benefit of TortoiseSVN with its superb Explorer integration. Perforce is a tad slicker in places and worth the money; but many will find Subversion more than sufficient. ®