This article is more than 1 year old
Subversion versus Perforce
Popular source code management tools go head to head
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. ®