Take control of your code with Perforce SCM.

By Mike James

Published: 26 August 2006

Software Configuration Management (SCM) is generally said to be what you need if you want to conquer the chaos of multiple developers working on multiple source files at the same time. In fact, with the right system, there are even advantages to be had from SCM if you have only one person working on one file! The Perforce SCM System has a client-server architecture, which makes it suitable for use by geographically remote development teams, but provides a central repository that is easier to manage. It’s a pure TCP system, so it works on a LAN or over the Internet, without the need for special configuration. The key feature of Perforce is that it takes an approach which allows a complete history of any file to be preserved and any previous version to be reconstructed – it’s not difficult to see that this ability has value, even in situations where the number of files and the team size are small. Indeed, it’s not just software development projects that would benefit from the use of the Perforce SCM, but it is the developer aspects, and its integration with Visual Studio 2005 in particular, that are of most interest in this review.

The first thing to say, however, is that there are various clients available and a number of IDE integrations. You can make use of a visual client for a range of operating systems, a web client, and a command line client. IDE integrations are available for Visual Studio, Eclipse, JBuilder and even for Office. Users can collaborate on a project via a client of their choice. Although a central repository of files – called a Depot – is used, each client works with local copies in a client workspace.

P4V is the standard GUI interface to Perforce

Perforce tracks client workspace activity such as file location, content, and pending file submissions etc. To avoid subtle problems of committing a subset of changes to multiple files one change at a time, such sets of changes are treated as atomic operations and hence as a single change to the entire system. Versions can be specified in a variety of ways: by giving the version number of the file; by specifying the date a version was created, or by using the unique depot-wide change id that is given to each set of changes that have been submitted, in which case the version retrieved is the one that was valid at the moment the depot-wide change was applied.

The user has to “sync” a file in order to work on it in the local workspace. The “edit” command is used to make changes to it, and the “submit” command is used to commit the changes to the depot. Within the Visual Studio IDE these commands correspond to “Get Latest Revision” and “Check Out for Edit”, both in the Solution Explorer window’s context menu, and “Check In” in the new Pending Check In window. Files that have changed or been added/deleted appear in this new window so that you know how you have modified the project. You don’t have to be connected to the server while working on the files – only for Check In/Out and other operations that affect the depot. The Visual Studio integration makes use of the standard SCC (Source Code Control) API, so should work with any IDE that supports SCC.

Admin strengths

In an ideal world we would divide a project down in such a way that one person could work on an aspect of it using a non-overlapping subset of files. In practice this is rarely possible, and parallel editing of files is often encountered. Perforce will merge two files that have been edited in parallel by comparing each with the base version that they were both derived from. The rules for merging are straightforward and usually deliver something sensible, but when they don’t, or when there is a conflict, you (in the role of arbiter or administrator) have to resolve which change should be incorporated into the depot’s topmost version. This idea of parallel development and the need to resolve conflicts is something that worries some developers. It should, but Perforce does highlight when there is a conflict and enables it to be brought to the attention of the people best equipped to resolve the problem – i.e. the people who made the conflicting changes.

Visual Studio integration is easy to use

Perforce organises files in a familiar tree structure that can be defined by the user. Individual files or entire projects can be branched off into parallel project trees. This is a second way in which parallel editing can occur. For example, if you are finalising release code but want to continue to develop the next version a branch will create a complete copy of the project. On the surface, this is consistent with what other SCM tools do, but under the covers, Perforce uses a technique called Inter-file Branching to allow the branching of complex and large-scale version trees. In the depot, Perforce only copies into the new version tree files that are actually changed from the original, which makes the process very efficient. You can also “integrate” (propagate) changes between branches; for example, bug fixes in the release branch can be integrated into the next version branch. Again this often needs some intelligence to be applied to make sure that changes are appropriate and to resolve any conflicting changes.

Perforce’s usefulness extends beyond the development stage in the life cycle. For example, there is a defect tracking facility that lets you record a “job” (change request) that can then be monitored. It also integrates with other defect tracking systems. There is also a reporting capability implemented as an ODBC driver that can be used with Crystal Reports, Access, Excel, and so on. The key factor, however, is the ability to work on multiple project lines – development, release and maintenance – that represent different stages in the lifecycle, safe in the knowledge that integration between the lines is manageable.

Creative control

You need to spend a little time making sure you understand the jargon, and organising how the system will be used, but in the main the Perforce SCM is natural for software development. It is also clear that there are lots of application areas where Perforce SCM would be particularly useful. Its own documentation makes a point of explaining how it can be used in web content management, and there are tools that allow versioning of graphics format files, but this is just the tip of the iceberg. The client application API is a C++ library that can be used to develop your own customised applications, and this represents a clear opportunity to build systems that make use of SCM in novel environments – technical documentation, product development, magazine production, research…

If you drag the slider you see the changes applied to the file in real time

This short overview has barely scratched the surface of Perforce SCM. It is a big and very flexible system with lots of components on lots of platforms. The key factor from a developer’s point of view is that it fits in with the way you want to work, and it does what you want it to do. In the final analysis you do need an SCM unless you really don’t care about previous versions. It provides a memory of the project that can show you how it all came about long after you have forgotten. It’s not even a matter of how big the project or the project team is – the ability to recreate previous versions and merge parallel versions is always useful, and Perforce does the job without getting in the way. Given that you can download a free two-user/five-workspace version from the Perforce web site, which can be used for any purpose for as long as you like, you don’t really have any excuses for not trying it out.

Perforce Software Europe, 0845 345 0116

Return to Articles