Fog Creek Software
Discussion Board

CVS vs Perforce vs ???

I few years ago I was introduced to CVS after having been a VSS user.  I will never go back.  The CVS way of just allowing everyone to work on the entire project vs the VSS way of only allowing one person at a time to check things out was a revelation for me. (1)

But, recently a friend of mine told me "Perforce is GOD".  We discussed it but I was hard to see why Perforce is better than CVS.  That particular friend switched from VSS to Perforce and since Perforce supports similar methods to CVS I can see that he also had the revelation that there is a better way.  But, that friend as never used CVS so he can't really compare it to Perforce.

He did come up with minor issues in Perforce's favor. The question then is, are minor issues worth $750 a person vs free?  I know Joel says "the best tools money can buy" but I can come up with extreme examples where that's not true(2) and besides, budgets are not infinite.

So, I'd really like to hear what people have to say about their various source code control software experiences and I'd particularly like to hear from someone that has used both Perforce and CVS.

Thank you


(1) For those that have only have used the VSS style checkin/checkout method you know that generally, in VSS you checkout a file, while it's checked out no one else can edit it.  In general all the source code on your local machine is write protected so you can't edit the files until you check them out.  If someone else has it checked out you have to wait for them to check it back in.  This can be hours/days etc.  Often I would resort to un-write protecting my local file, editing it and then hand merging the differences when I was finally able to checkout the file.

CVS on the other hand uses a method where you just edit any file you want at any time.  When you run CVS you first tell it to get all changes and it merges the global files on the server with your local files.  Then you can commit your changes in which case it will merge your changes with the global files on the server and update the files on the server.

If two people have edited the same file it tries to figure out how to merge them. 98% of the time it's fine.  If it can't figure it out it will run a diff program of your choice and make you manually merge the differences.

The huge win is you never have to wait to edit files.  You just work almost as though it was just you.

(2) I once worked at a company where our producer thought Alias PowerAnimator was the "best tool".  At the time, Alias PowerAnimator cost $60K a seat!!!!  $30k for Alias PowerAnimator and $30k for an SGI to run it.  We had 3 artists so 3 seats or $180k  For that price, if we had used cheaper 3D software we could have hired 2 or 3 more artists.  6 artists will very arguably be more productive than 3.

Gregg Tavares
Thursday, September 26, 2002

Can't reply to Perforce.  VSS allows "multiple checkouts" and also has the 98% successful merge rate.  And it's nicely integrated in VisualStudio.  That's not the problem.

The problem with VSS is database corruption.  We've suffered it.  And, no cross platform compatibility with MacOS X.  The later being the showstopper.  (The prior would be a showstopper if we didn't do daily backups of the massive database.  It's just a royal IT pain when it happens and we have to regress.)  So we're using CVS, too, which has never failed us yet.

Am also interested in CVS vs. Perforce.  Will watch this thread.

David Blume
Thursday, September 26, 2002

VSS too allows multiple checkouts, and it worked for us: there's an option you can put in the SS.INI to let several people check-out a file using VSS (the option is disabled by default). The first person to check-in then has no problem, VSS assists the second person with an automatic merge, with perhaps a GUI intervention if there's a merge conflict.

Christopher Wells
Thursday, September 26, 2002

One of the nice things about VSS over CVS (in addition to the IDE integration) is knowing who has a file checked out, which can be helpful in determining ahead of time where conflicts are likely to happen, and also in determining when everyone has "finished" working on a bit of code.

As I understand CVS, you never know who is working on a file until they check it back in. Is that right?

Andrew Reid
Thursday, September 26, 2002

To answer my own question....

CVS can optionally be set up to tell you who is editing a file via the "watch" and "edit" commands options.

Andrew Reid
Thursday, September 26, 2002

I have personally used both CVS and Perforce extensively. And when I moved from CVS to Perforce, it definitely was an "upgrade". A few of the really good reasons why the 750 bucks is worth it
a. A commit is a transaction - How many times have you started a long checkin on CVS, and the network or something goes down, and you have code breaking. In P4, an entire commit(submit) is an atomic operation. This is a real blessing, because you can be sure that a checkin will never break the code (Provided you have verified it doesn't before checking in!!!)
b. P4 is not as chatty as CVS - P4 maintains state on the server, which means you do not have those dirty /CVS directories in your code. What CVS does in order to do an update is, it communicates to the server(repository), which version of the file it has. Then the server figures which file version to give it. And this is done for each directory in turn! The volume of communication is very large between the client and server.
c. P4 maintians labels as references to the file versions instead of placing a marker on the physical file itself.
d. P4 maintains differenct branches as distinct files - Unlike CVS where all branches of a file are marked on the same repository file
The above two combined, give you a much superior performance when it comes to labelling and branching. I have persoanlly faced situations where we have had to maintain a large number of branches, and releases on each of these branches.
CVS locks each file its trying to label, and if you are labelling the whole source tree, every developer's work is pretty much frozen. In P4 labelling a whole source tree (of about 5000 files) takes 2 minutes flat.

Apart from this, pretty much everything that CVS provides is provided by P4, including watching, auditing etc.

The bottom line is this: If you are working on a really large project, with a lot of source branches go for P4. If you are working on a WAN (as we are) go for P4. If you run a single or dual branch software shop, with everyone sitting in the same place, go for the free alternative. You won't notice the difference.

Rajesh Jayaraman
Friday, September 27, 2002

You may wish to search the perforce email list (
as the perforce vs X questions have been addressed
a lot. The nice thing about perforce is that it generally
works and when it doesn't tech support is great.
With CVS it seemed we were always fixing something.

Friday, September 27, 2002

I think the most revealing support for Perforce comes from Pete Insnee, an engineer with the Microsoft Xbox team [1].  In his speech, he says the Xbox team passed on VSS and built a propietary system to handle code management...  which was very similar to Perforce!  In my experience, Perforce is great for larger groups, where you benefit from branching multiple codelines (and where you can afford it!).


Friday, September 27, 2002

We switched from CVS to P4 for the following reasons:

- branching - CVS's branching support is a joke. You can branch, but merging doesn't work that well after the first time. p4 makes branching easy for developers, and it does a really good job on merging because it keeps track of the base/last merged revision. In CVS we only used branches for patches to old revisions. Now we use branches a lot more in developing new features which made it much easier to stabilize mainline at intermediate milestones.

- atomic commits (described above). This is very helpful in figuring out what files were affected by a specific bug fix.

p4 has been more stable, or at least, appears more stable than CVS.

The other features that p4 has out of the box that we are planning to use are  integration with defect tracking via jobs and check-in reviews.

Friday, September 27, 2002

Has anyone here tried Subversion ( yet?

The project looks a lot like an attempt to make a CVS that works more like what you're describing Perforce as.

Chris Tavares
Friday, September 27, 2002

Actually its a fairly open secret that Microsoft purchased source-code license to Perforce for Win32 development (3000+ developers)

(This is not to disparage Pete Isensee at all - I know Pete a little, he's a great guy.)

Below is my post to the Perforce user mailing list.
I got several private replies along the lines of "Sssh - we can't talk about that."



[p4] Was Perforce ever called "SourceDepot" ? (And did it save Window s XP development?)
Chris Newcombe
Fri, 31 Aug 2001 09:35:25 -0700

A fascinating presentation on the entire history of Windows NT development, by one of their senior engineers.

Partial summary: For years (through Win2000) they were crippled by a slow, non-branching SCM system which serialized all development (e.g. all check-ins required explicit email permission). Then (in 1999) they selected
a new system called SourceDepot, which basically saved the day for Windows XP and has transformed the development culture.

I'd never heard of SourceDepot before, and a Google search found almost no references.  But it did find the following (snipped) message in the Perforce mailing lists...

Jos Backus
Wed, 24 Jan 2001 17:22:45 -0800

% p4 help undoc

!!!!!!!!!!!!!!!!!!!!!      ***********
    Unsupported or obsolete SourceDepot client commands:
!!!!!!!!!!!!!!!!!!!!        ***********
        admin      Perform administrative operations on the server
        dirs      List subdirectories of a given depot directory
        flush      Fake a 'sd sync' by not moving files
        get        Synonym for 'sd sync'
        refresh    Refresh the contents of an unopened file
        reresolve  Repeat a previous integration merge

So is SourceDepot really Perforce? Perhaps MS don't want to use the new name because of the potential bad press for VSS?


Chris Newcombe
Friday, September 27, 2002

As a point of information, the old Microsoft source code control system was called "SLM", and was based on a very old unix source code control system of the same name. (Remember, before PCs replaced workstations, Microsoft used to do a lot of development on Unix boxes.)

SLM was in use long before Visual Source Safe existed.

Each group had its own incompatable version of SLM, and if you were doing cross-group development you could actually corrupt one group's sources by accidentally using another group's version of SLM to check in.

Switching from SLM to Source Depot really did speed up internal development quite a bit.

Anonymous Microsoft Developer
Friday, September 27, 2002

Andrew Reid wrote "One of the nice things about VSS over CVS (in addition to the IDE integration)  ...."

For the last two years or so, CVS has _significantly_ better IDE and Shell integration than VSS. This isn't very well known because awareness costs money.

Jalindi Igloo [ ] integrates CVS into the IDE and does a wonderful job; If your repository is 'cvs watch'ed, it will alert you that someone has already checked out a file for editing - though it won't stop you unless that checkout was specifically marked exclusive. In sharp contrast with the VSS integration, it plays well with branching, whose value in both CVS and VSS can be questioned, but I think not being able to use them from the IDE kind of kills any usefulness of the VSS/IDE integration in a professional setting. (And ... many projects ARE using CVS branches successfully; They're a bit awkward but they mostly work).

Tortoise CVS [ ] is what integration SHOULD look like. They call the project "Enjoyable version control", and I think they live up to it - it adds CVS shell menus that work everywhere (explorer, file open dialogs, etc.) and let you check-in / check-out / update / tag / branch / merge / whatever by right clicking. Version and status indicators (being edited, up-to-date, needs check-in) are added as icon overlays to both files and directories, and as columns that you can show in explorer. All file versions, branches and labels are listed under a new "CVS" tab in the property page for the file. Textual description can't really do it justice, and neither can screenshots - It's intuitive, it's stable, it's enjoyable and it rocks. Try it. [Oh, and it also works well with a local repository, so you can start using it for everything without having to have a server available - and once you're hooked and need to go wide area, it can securely use remote Unix or Windows servers, and even do automatic WinNT domain authentication against a remote CVSNT server].

I suspect it's simple enough to get non techie workers to version their stuff with Tortoise, but I haven't tried it yet. I wouldn't think of introducing VSS, WinCVS or Perforce to anyone who isn't a developer - but tortoise might work. If I were developing P4 or BitKeeper, a TortoiseCVS compatible shell would be my the most important feature on my todo list.

Ori Berger
Saturday, September 28, 2002

I use WinCVS and knew that Tortoise existed, but I was to lazy to check it out. Also, a CVS Windows Explorer integration did not seem like a very good idea. There are way to many applications already that add useless entries to my windows explorer context menus.

It turns out that I was wrong. Tortoise is a great addition to CVS. Thanks for pointing it out.

Jan Derk
Tuesday, October 01, 2002

I also have heard from reliable sources that Microsoft's primary internal version control system (called "Source Depot") is essentially a modified build of Perforce, and that this is what controls the 750,000 (something like that) source files that make up the Windows XP code base.

Jeff Morrisi
Thursday, October 03, 2002

Check out (pun intended) the BitKeeper web pages. They have comparisions with both CVS and Perforce. It is biased towards their own product but is worth a read. I believe their own tool is a tad bit too expensive for most software development efforts, but it is the only one that scales enough to be used on the Linux kernel.

Wednesday, October 16, 2002

*  Recent Topics

*  Fog Creek Home