A Look at the Perforce Version Control System

Using the right tools for the job is always important; with tools that become components of your software production line, it is crucial. The capabilities and limitations of these tools have a direct impact on the capabilities and limitations of the entire organization.

Perforce—a version control system with ready hooks for integration into bug tracking systems—is one such tool.

A few years ago, Monster  was in the market for a new version control tool because they realized their software production capacity was hindered by the limitations of their current system. They brought me on board to help. After establishing criteria and evaluating a few top products, we selected Perforce. Now, after more than two years in active production use, Monster and I have found Perforce to be ideally suited for their Web development environment.

Works for the Web Development Environment
Monster's demanding Web development environment poses great challenges for a version control system. Unlike traditional software development environments, Web development implies a faster pace of change, a much larger number of files, and a greater diversity of contributors (including nontechnical content producers). Monster's contributors are geographically dispersed, coming from about a dozen sites in nearly as many countries. At the time, many of them came from newly acquired companies, and therefore were running on a variety of different operating systems.

Perforce's lightweight architecture, high speed, and capacity to handle large, distributed development environments make it a good fit for Monster. The lightweight architecture requires only TCP/IP communication between client and server machines, making it very easy to connect users from remote locations. The Perforce server is extremely fast, and is exceptionally frugal with server and network resources, which translates into high usability on the central server from anywhere in the world. The Perforce client runs on just about every platform I've ever heard of—over fifty in all. Although Monster's primary platform is Microsoft Windows, they didn't need to force remote locations to switch operating systems to bring them online with Perforce. That lowered the resistance barriers for remote teams as Monster brought them into the fold and under the direction of the central Release Engineering team.

Requires No Formal Training
Initially, we had anticipated a great deal of difficulty with setup and training for the remote users. Monster literally doesn’t even speak the same language as all of its users. However, Perforce is easy to use and installs in minutes, so the users needed no formal training to get up and running. (This was a bit of a bummer, since I was hoping to have an excuse to travel around the world!)

Makes Branching and Merging Manageable
Monster's environment has two paths to production: one path for functionality changes that follow a traditional develop/test/release cycle, and a separate, simpler path for "look and feel" changes that don’t require formal QA by a separate group. Often these different types of changes affect many of the same files. Prior to Perforce, changes from the functionality path would often collide with changes from the look and feel path, with less than ideal results.

To make two paths to production work, Monster needed to branch and merge. Branching allows several people to work on the same file at the same time, but be momentarily isolated from the changes that other users are making. For example, a content producer in France might edit an HTML file