Good Tools Are Worth Paying For

I definitely would not have survived the past couple of days at work without Perforce, the version control system of champions. I’m sure there are version control systems other than P4 that are just as good; it’s just the particular flavor of crack that I’m addicted to. It just seems like the ubiquity of CVS, the de facto standard for open source projects, is yet another great example of Worse is Better. Most open source projects you meet use CVS, which stands for “Concurrent Versions System.” Everyone uses CVS for exactly two reasons:

You’ll even find advocates on the web explaining why you should use CVS even though it’s totally broken. These advocates conveniently overlook the fact that CVS sucks. Let’s review, shall we?

So when people call CVS “version control” you need to realize that that’s a very optimistic description. It’s really more of a hope.

There’s just something about this topic that makes people’s willing to accept a level of badness that they wouldn’t take for a minute, in, say, their OS, or their text editor, or their web browser. Do you think people would keep using Emacs, even though it is both free and Free, if, periodically, it just decided to corrupt the files you were editing? Yet when it comes to version control, people accept just that. For example, here’s a CVS apologist I found on

“CVS expects you to trust merges. A lot of people don’t, usually saying how they once spent hours resolviing [sic] a horrible merge. It doesn’t occur to them that the problem was not source-control but bad process - two developers editing the same part of the same file, with at least one failing to synch with the server often enough.”

Wow, imagine that – people failed to realize that their version control system didn’t actually control versions of the files they were working on. Those crazy kids with their loud rock and roll music and their hamburger sandwiches and their French fried potatoes!

Think about that claim for a minute. Implicit in it is the idea that any software process model where more than one developer is working on a given region of a file at a time is broken. I guess that’s a workable theory, if you don’t actually have deadlines, or competent developers. Perhaps the lack of deadline pressure is the whole story of why CVS is adequate for free software (as opposed to Free Software – there are open source software products which are sold for money and therefore have some deadline pressure). But since CVS provides no locking or notification support, how do I know if someone else is working on the same files I’m working on, anyway? What’s my process if I work in a company with 10 people? Do we all send out mail saying “I’m editing the fold_monkey() function in monkeybagel.c now”? What if I work in a company with 50 people? 100? 500?

The idea that process should adapt to the inadequacies of the tool is insane. When a tool is inadequate to good process, you should find a better tool. (In this particular case, the inadequacy is not “CVS doesn’t do notification,” but “CVS doesn’t do atomic checkins or make complex merging workable.")

Here’s another one that I just have to share, and let’s be frank, mock:

“CVS is indeed the best version control system I’ve used."

Translation: CVS is indeed the only version control system I’ve used.

The best version control system I’ve used is Perforce.

So what is Perforce? Perforce is basically CVS if CVS wasn’t designed by hamsters on crystal meth. Just about every problem you can identify with CVS is fixed in perforce. There are command line tools that are disturbingly similar to CVS’s, with the difference that they actually work. There’s a Windows interface, if that’s your thing. There’s a (good) web interface. Hell, there’s even a Half-Life interface to p4. Multiple users working on the same file works intuitively in p4 (the integration procedure is pure love). Multiple branches and/or multiple client views into the same or different branches are easy as pie. You can manage multiple changelists, all checkins are atomic, it’s backed by a database, and reverting to earlier versions of the tree (or a branch, or a file) is simple.

The basic unit of a P4 checkin being a “changelist” has another consequence: you don’t check in files to Perforce, you check in a changelist. So if I say “I want to see the specific fix that Bill checked in that fixes bug 14982,” it’s trivial, no matter how many files it touched. Try doing that in CVS.

And, most importantly, if you’re working on a project with more than three people, you won’t want to go hang yourself every time you need to check out or check in a file. At least not because of the version control system.

Random links: This [discussion thread over at Joel on Software](http://discuss discusses some of the differences in a slightly less antagonistic tone than I’ve used here. It’s a good read. Ned Batchelder blogged a bit about this too. Dana Epp is looking for advice on which SCM system to use. I plan to tell him to use Perforce; drop by and counter my advice if you disagree.

Perforce is a commercial product, but it is free (as in beer) for two users or less, and they’re pretty liberal about issuing evaluation licenses so you can see what you’re getting yourself into. It may seem comparatively expensive at $750/seat (less as you buy more seats) once you are working on a big project, but at my company, at least, it has been worth every single penny. And they claim that they offer free licenses to Open Source projects. So check it out.

What version control do you use? Have you killed anyone yet?

Update: See my article about using Perforce on Mac OS X.