andrew carter

I came across this post on why perforce is not so good. I use Perforce at the company I work for and I used the Perforce fork Source Depot when I was at Microsoft. There were many things that I did like about it but something always kept me from really loving it as an SCM. This article really captures the same issues I have with it.

In no particular order, these are my complaints about Perforce:

Clients

The first major problem is that the server must know about all clients. Technically, the only things that are useful in this model is that you can see everyone else who is currently editing the file and you don’t need CVS-style local tracking files. I suppose that is useful if you want to know who will get affected by your changes. The other “useful” reason is that it makes it easy for Perforce to manage licensing since all clients are centralized. As a developer/user, this model is terrible. It is unnecessarily complicated to create a new enlistment. Checking out requires creating a new client just to create another sandbox.

Checkout model

Everything is locked until you check it out. The only useful thing for this is to make you think about whether you want to change a file. But it is useless. It is a pain and many IDE’s screw this up. A sandbox where I can make any change I wish and reconcile with the server is much more useful. Specifically for Perforce, it is a real pain to see when you haven’t checked in a new file. That’s more a failing of the P4 client than an inherent design flaw in the server. Almost weekly we have someone forget to checkin a file.

Offline discouraged

Perforce is nearly unusable offline. The solutions for this are a hack at best. Contrast that with subversion which absolutely thrives offline. Perforce is really only useful to developers tethered to their desk.

Database

I think Berkeley DB is a decent storage engine. But it sure has problems on Perforce. For example, our dev manager recently re-organized the development tree and we literally lost nearly a full day because the database had to crank through so much work to catch up. Branches are expensive. And you are absolutely screwed if the db is messed up. Subversion realized this as well as they have switched to a file-system backend for newer versions of SVN.

Alternatives

I strongly prefer Subversion over Perforce. Subversion has the benefit from learning from others limitations and solving those problems. The big reasons though are that every one of my major Perforce complaints are solved in Subversion. Factoring in the license expense, Subversion seems like a slam dunk. Unfortunately in my situation, our dev manager has heard from others that complained about Subversion’s performance and went with Perforce instead. I haven’t experienced this problem personally but it’s something I would like to research and hopefully disprove.