Subversion versus Perforce
Popular source code management tools go head to head
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.