At work, I’m now forced to use the Perforce version control system, since that’s what our company has standardized upon. I’ve had some bad feelings about that from the start (based on reading about it), but I’ve hold off on publicizing them so I could give Perforce a fair chance. After all, I have been wrong before ;). So now that I’ve worked with it for several months, here’s my verdict.
Speed
The Perforce slogan is Perforce, The Fast Software Configuration Management System. So they’re basically claiming that they are faster than their competitors. How does this claim hold up?
That question is not so easy to answer, since their competitors are not a homogeneous bunch. But let’s look at one category of competitors: the distributed version control systems. The most well-known of these are Git, Bazaar, and Mercurial. Interestingly, Git calls itself The fast version control system and Mercurial’s slogan is Work easier, Work faster.
Distributed version control systems work locally, meaning they don’t need a network connection. Contrast this with Perforce, that needs a network connection for everything. And I mean everything, to a ridiculous level. For instance, even the help command needs a network connection:
$ p4 help
Perforce client error:
Connect to server failed; check $P4PORT.
TCP connect to perforce failed.
perforce: host unknown.
Now, obviously network access is going to slow things down a lot, so it’s difficult to see how Perforce can still beat their competitors on speed. And my experience has been very clear: it doesn’t! In fact, Perforce is very slow. Now obviously, that depends on your network bandwidth, so your mileage may vary.
But it gets worse. My primary interface to Perforce is not the command line client, but the Eclipse integration, P4WSAD. And although Perforce claims that this is the best of both worlds, my opinion is that this is a piece of crap. There, I said it. P4WSAD makes my life as a developer a hell.
Perforce makes all files read-only by default. Only once you’ve checked out a file, will it become writable. And, you’ve guessed it, that requires network access. In practice, this means that everytime I want to change some source file, I have to wait until P4SWAD checks out the file, which can take up to five seconds! This is extremely annoying, because it completely breaks my flow. And if you think one file is bad, try doing a refactoring that affects multiple files… It is reason enough for me to not ever want to work with Perforce again.
BTW, it is interesting to note that none of the aforementioned distributed version control systems appear in Perforce’s comparison with its competitors.
More connection troubles
Now if all this slowness actually bought me some nice features, that could change the story, right? Well, yes, it could. But it doesn’t.
The same cause for slowness, accessing the network for everything, is also limiting what you can do.
For instance, I have a long commute in the train, so I like to work there. And guess what, I don’t have an internet connection there. Not to worry, Perforce has a workaround called offline mode. This basically means that P4WSAD will nag you for confirmation every time you try to change a file.
It also means that it looses track of which files were changed, so that when you get back online, you forget to submit some files and break the build. That has happened to me quite a few times now, because the reconcile feature is not available in P4SWAD. You need to use the Perforce Visual Client (P4V) for that. So now I need to use two tools to get my work done.
Another limitation of P4WSAD is that it will block a refactoring affecting a file that you haven’t already modified since you went offline. This means you have to hunt down all the places where, say, a method to be renamed is used, and force a “checkout” of all those places by changing something in the file. Only then can you do your refactoring. Very annoying.
Transactions
Perforce claims to support transactions, which is a must for a source code control system. We don’t want our automated build to pick up part of a set of changed files and break because of that!
Unfortunately, transactions in Perforce only work when they work. In other words, when an error occurs, it’s very well possible that Perforce will have comitted only a subset of the files in the “transaction”. This is not a really big deal, as it doesn’t happen all that often, but still.
Directories
Perforce is completely file based; it doesn’t track directories. So it’s impossible to add an empty directory to a repository, for instance. Also, when someone removes a directory, Perforce by default will leave empty directories on people’s file systems when they synchronize. There is a setting to fix that, but it’s set to the wrong value by default. I consider this only a minor flaw, but it’s annoying nonetheless.
Conclusion
Would I recommend Perforce to anybody? Not really. I think there are better alternatives out there. Free ones, mind you. So save yourself some money and check out (pun intended) Git, Mercurial, or Bazaar.
Secure Cloud Development 
I have been using Perforce Client (P4V) with Team City to perform automated builds. The builds can take up to 5 hours.
Team City uses Perforce Client (p4 commands) to get the files it used to build from a Stream of the Perforce Repository. Since it only needs some of the “Folders” or directories from the Stream to build, Team City maps those “Folders” in the Streams on the Perforce Server, it needs, to “Folders” or Perforce Workspace on the local machine.
However you cannot get Team City to check-in any changes it makes, back into the Perforce Server, because Team City of the way Team City creates this Perforce Workspace. It automatically creates a dynamic Perforce Workspace, which does not have any Stream associated with it.
You can check the files back in if you tell Team City if you create a static Perforce Workspace with the Perforce Client, associate a Stream with that Workspace, and tell Team City to use it.
But if you create this Workspace from a Client, the Perforce Client attempts to get all the Folders from the Stream. This takes a long time. And it is not necessary. So you cancel that task. And use the p4 commands to manually fetch the Folders you need from that stream into the Workspace.
As you fetch the Folders, you can see them appearing in the Window of the Perforce Client. But the Perforce Client then starts deleting the Folders. It gets confused. Presumably because you did not fetch the Folders with the Client. Whatever the reason, the Client should not be deleting Folders you put in the Workspace for whatever reason. A Version Control system that actually deletes Folders and files when you do not tell it to, is the very antithesis of Version Control. Version Control systems should make you secure about making changes to files in large projects. It should not frustrate and fights against you when you are trying to do your work. And it should never be deleting stuff without permission.
Never mind these Perforce apologists. I do not know what Perforce is. But it is not a Version Control System. I agree with the reply which says that Perforce is much worse than you stated. Life is too short to waste time on this stuff. Some people have an emotional and financial attachment to software and refuse to see the flaws in it, when it is clearly staring them in the face. They are both ignorant and proud (a lethal combination if ever there was one). Do not waste your time arguing with them. I have only used Perforce on Microsoft Windows not on any other Operating System. It may be better elsewhere. But its diabolical performance is very much in keeping with the Buggy Software you get in the world of Microsoft Windows. As is the complete insensitivity and ignorance of those trying to defend it.
Sincerely,
Rod.
I’ve been using Git and SVN for years but for the last 4 months I’ve had to use Perforce for a contract. My own productivity has plummeted because I am constantly fighting against Perforce. Many of the other developers I work with have not used Git so they don’t realize how much easier things could be.
Found this discussion by googling, “perforce is the worst”, can’t agree more, it’s horrible.
Just came across this article, and I have to say it is wildly inaccurate. Perforce is much, much worse than you say it is.
How they have the cheek to charge for it is beyond me.
I have to disagree about Perforce’s slowness. It is far faster than subversion and when working over distances, it is blazing fast.
I also work disconnected a lot…perforce doesn’t need a network connection.
One other thing I’d like to point out, the time that I’ve spent with Perforce, its transactional operations have NEVER failed me. If something was wrong, the checkin failed and all files were left as they were before.
Once I fixed whatever problem was there (a merge, or some conflict, out of disk space, whatever), the checkin was able to complete.
Perforce is a fine product and and has exceeded out expectations.
For what its worth.
I’m glad Perforce is working out well for you. Wish it did for me.
Rémon, I didn’t suggest you should like using Perforce. Since you are forced to use it, as I am, I thought you would appreciate some advice that would make using it easier.
People at my company were discussing your article because of your statement “that [Perforce] needs a network connection for everything” as a reason for not using it. I just wanted to show that is not true and that Perforce does support an off-line workflow (though not as well as you would like).
I’d like to see any client-server system perform well under the network setup you’ve described, and for that reason Perforce does seem like a poor choice for your organization. For my organization, with my office only a short walk from the server, it works very well.
Perforce gives you the choice between Eclipse plug-in, Windows Explorer plug-in, stand-alone Visual Client, command line client, and probably some other interfaces. Like you, I have a lot of work to do, so I use the best (often the quickest) tool for the job. I don’t like the Eclipse plug-in either, so I use a combination of the Visual Client and command line depending on what I’m doing. If you are spending too much time fighting with Perforce just to check out files, then I suggest you learn better ways to use the tool. Instead of checking out files individually, I check out the entire project. And when I submit, Perforce automatically ignores files that I did not modify. Both tasks only take a few seconds.
Larry,
I would. Unfortunately, you haven’t given me anything useful yet. And since I did do my homework, I’m not getting my hopes up that you will.
I’m fully aware of that. In fact, my post describes how much it sucks.
My point exactly, wrong tool for the job. We should be using a distributed version control system like Git.
Great advice in general. But who says I haven’t tried that? Trust me, we have an office full of bright people would have tried all sorts of things. The only thing that seems to work, is work around Perforce using Git (see Martin’s comment). But that only works for those on more mature projects than I am on, where each individual doesn’t need code from others multiple times per day.
Well, that’s the thing: it doesn’t in my environment. The network latency is just killing me.
Perforce does not require constant network access to the central server. I’ve been using it for over 10 years, and I generally only connect to the server once in the morning to fetch the latest version of the project files and once in the evening to check in my changes. The trick is to edit your workspace settings to enable the “allwrite” and “clobber” settings as described here:
http://www.perforce.com/perforce/doc.current/manuals/p4web/help/editclient.html
I’ve also never found it to be slow, though that is entirely dependent on the speed of your network and server. If you don’t like the Eclipse integration, then don’t use it. I never do, instead preferring interface of the “Visual Client” (p4v.exe) and sometime the command line for scripted integrations.
Well, my environment is a bit more agile, so that doesn’t work for me. If you are happy with Perforce, by all means, keep using it. But don’t tell me I should like this tool.
The Perforce server is in California, we have a proxy in our office Rotterdam (The Netherlands) but I often work from home. When I do, my VPN connects me from Utrecht to Ireland to Rotterdam to Pleasanton and all the way back. I don’t care how fast the protocol is, but that kind of setup will always be slow. It’s just the wrong architecture for the job. BTW, I’m not blaming this on Perforce, but on the people who’ve selected it.
By that logic I wouldn’t be using Perforce at all 😛
Seriously, though, your comment doesn’t make sense. Do you really suggest I first find all the places where a method is called, then check out all those files in P4V, and then go back to Eclipse to finally rename the method? I don’t have time for that kind of crap, I have work to do. YMMV.
Very much agreed. To Perforce’s credit, they rely on a central server model, and this probably works fine as long as you’re in the same building as the server. In our case, the server is on a different continent, which explains a lot of the performance issues. I guess Perforce just doesn’t work in that setting.
But the good news is that you can use a Guerilla Git system pushing/pulling from/to Perforce using git-p4. You only have to endure the slowness when you commit, e.g. once a day.
Martin,
Would you care to write up a little something about this guerrilla Git system?