Perforce vs. CVS

Sunday 11 May 2003This is 20 years old. Be careful.

My offhand mention of switching from CVS to Perforce for source control at work brought an email from a friend. His company had also just made the same switch, and he wanted to know why we switched, how we chose, and what we thought so far.

We switched because our CVS server seemed a little flaky on Windows, and because CVS seemed uncertain with complex branch and merge topologies. We also knew we would get other benefits from switching, like tracking changes to a number of files as a single changelist rather than as a number of revisions.

We chose Perforce over ClearCase because our developers who had experience with Perforce loved it without reservation, and our developers who had experience with ClearCase loved it but said it took a lot of work to setup and keep running. Also, ClearCase was very salesperson-heavy, while Perforce would let you download the code from their website.

As to my impressions, here are the things I like better about Perforce and the things I like better about CVS:

First off, keep in mind that I have been using Perforce for about two weeks. I’m usually pretty quick at learning new tools, but I could be overlooking things Perforce can do, or ways it can do them. Feel free to teach me!

Perforce’s wins:

  • It’s much faster than CVS.
  • It treats a number of files changing at one checkin as a single changelist rather than a number of revisions. This is much easier when propagating changes from branch to branch.
  • Its architecture is built to accommodate scripting. You still screen scrape a command-line utility, but the utility has been designed with that use in mind.
  • Trent Mick’s is marvelous, and has done all the screen-scraping already.

CVS’s wins:

  • It’s cheaper.
  • .cvsignore files let me teach CVS about files that were not supposed to be stored in CVS. Perforce has no such concept.
  • CVS did a better job alerting me to the fact that I had created new files which needed to be added to CVS.
  • CVS would merge files changed by more than one developer automatically. Perforce will do the merge, but only if I tell to auto-merge. If the most merges don’t conflict, then why not just do it and let me know when conflicts happen? Maybe there’s a philosophical difference here that I am missing.
  • CVS was better at off-line work (when you are not connected to the server). Perforce can accommodate it, but it’s got more of a disconnect-then-work-then-reconnect feel to it. With CVS, there was no need to communicate with the server to get work done, just when it was time to check code in, so disconnected work was very natural.

Things I don’t like about Perforce, though I can’t claim that CVS is better:

  • The Perforce merge tool is an ugly unwieldy confusing mess. Maybe I just have to get used to it.


I must react since my email was the thing that set you off. As for the merge and diff tools. The merge tool can be a nightmare, so a lot of folks have switched to Araxis Merge, which costs about a billion dollars. If you run into a lot of conflicts, this is your tool. For myself, I have not yet run into anything that was difficult (working in a lonely playground) so I am OK.

For branching, we created a developer's depot where each developer has their own branch. It is a little more work "integrating" your branch (synching back and forth from the main branch), but the ability to check in and check out revisions of your own work prior to submission is very nice, plus it is a built-in backup system!

I have been using Beyond Compare (Judd's tool) for diffs, for $30 a copy it is worth it.
There is a new merge tool coming out soon which I have hopes for! (Written with QT).

Meanwhile, you can add mappings to your client view specs to ignore certain files (like .cvsignore) if you want.

Perforce takes a little while to get seriously to grips with (as opposed to just getting set up and basic check in/out) and I would recommend the Perforce User mailing list and browsing the Documentation/White Papers/Public Depot etc.
Per-client view mappings can help to focus Perforce on the files it should care about, but how can I do that in a way that all of my developers will use them?
On Unix for merging I use emacs's 3 way diff for merging and have done pretty complicated merges.

It is a bit of a hack, but works great.

Send me an email if there is any interest in the actual command to use.
You can put a line in your protection table to exclude build cruft. Say you don't want .lib files. Tryt this:

write user * * -//....lib

That will remove access to all lib files. Of course you can be less heavy handed by only applying it to certain paths.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.