Dear Perforce:

Fuck you.
Fuck you, you miserable, untrustworthy, misleading, overpriced bastard. I hope your office goes up in flames along with all your off-site backups. I pray that some open source product that actually works is embraced by all the major companies and drives you out of business. I hope that no other company is duped by your salespeople into thinking you have something even remotely close in quality to the ancient and craptastic product known as CVS. Never before have I experienced so much pain in the most simplistic of version control tasks as I have since starting to work at a company that made the mistake of considering you.

I am in total agreement with Linus that CVS is evil and that anyone who chooses to use it knowing the alternatives is both “stupid and ugly”, but I would switch from Perforce to CVS in a heartbeat. I would bow down an kiss CVS’s authors feet if I could avoid ever using your self flagellation “tool” again. I am currently the only one working in my codebase:

Four times now I have come into work, started coding, and opened up a file that I edited, and submitted the day before only to find it’s at some prior version. Telling perforce to sync it just results in it telling me it *is* in sync. The end result is that i have to do a sync -f (which tells it to forcibly overwrite everything every morning or else risk screwing over my repo by editing and checking in a file that was rolled back without it telling me). No, unit tests don’t catch this problem because it will roll them back like anything else, and since I never intentionally check in failing code the test from before the mysterious rollback gives me a green bar just like the one after the rollback and it’s not like I memorize the number of tests I have in each project at the end of every day. Today it forced me to merge in “their” changes. Except I’m the only one working in the damn branch, and I’ve only got one “client” that refers to it.

When you try and “integrate” (otherwise known as “merge”) files from folder A (where you’ve been working) into folder B it will tell you that “their” stuff has changes but “your” stuff is fine and would you like to accept “their” changes? You see “their” changes are the ones that YOU made in folder A and “your” changes are the ones (if any) from folder B that you weren’t screwing with and are trying to merge into.

It changes the file permissions. It changes line endings. Yes there are preferences for both of these but there shouldn’t be. A version control system should never alter the files you put into it in any way. The command line tools are pure crap. If you want to do anything that isn’t trivial you essentially just have to use the GUI.

It’s not smart enough to understand that a file that you’ve changed… wait for it…. is a file that you’ve changed!!! oh sure you can say “Please Mr. Perforce, I’d like to edit that file there please” and then it will know, but you can’t just edit a file. That’s crazy-talk in perforce land. If you try successive rollbacks of changesets it will start bitching about not wanting to clobber files that it just made writable when you did the last rollback even though you haven’t done anything but tell it to roll back a few times.

It can’t scale. You want to put terabytes worth of data in it? It’ll let you, but if you dare try and request it you’ll either take down the box or prevent anyone else from being able to do anything on it.

It alters file permissions in some 17th century attempt at “locking”. This is probably due to the fact that it can’t just tell that you’ve worked on a file. By making the files read only it forces you to tell it that you want to edit it, and thus enables it to know you’ve edited it. It will get confused and bitch about needing to submit files so you’ll tell it to submit but then there aren’t actually any files that need submitting so it creates a changeset with no files in it and then refuses to submit the changeset with no files in it. This changeset will then sit around mocking you until the sun explodes or you go and delete it… delete the file that it told you you had to create and then refused to accept.

It makes me waste hours every week fighting with it.

Pitchforks and vile thoughts, -masukomi

Update: Please note that I’m not just bitching about Perforce. No, I don’t like it, but I’ve done something about it. I went and wrote a tool to sync perforce with various Distributed Version Control Systems, but then I came to the conclusion that Git was just too damn cool to bother with the other ones, and switched to using Git with it’s git-p4 tool to sync to Satan, er, perforce. If you’re interested in that it can be found in the contrib directory of the git source. Just copy it to somewhere in your path and you’re good to go (requires Python).

Followup:

There have been quite a few comments and criticisms of this article, bot on this blog and on Reddit, and what follows is a rebuttal to those so please feel free to skip it. The comments could basically be broken into three categories, but before I go into any of them I must point you to the best damn response anyone had to that post. Thanks keithb.

I’ve used it for n years and it’s never screwed up a file / been unstable /gone down comments:

I’ve been using it for 4 years on my own project, never once running into any of the problems you talk about. -Michael G

I only ranted about one thing that was broken (my weird rollback issue) everything else was an issue I had with something intentionally coded by Perforce’s developers.

Perforce is not breaking for me. It’s behaving as designed, and that’s almost as bad.

To be totally clear: Perforce has recorded everything correctly, except for the fact that it will change line-endings on you, and yes I realize there is something you can config to control this, however I’m of the opinion that your version control system should never be second-guessing what you meant to stick in it. No files were corrupted or lost, and I don’t expect that it will do so at any point in the future.

I’d have to say that whatever its faults, it’s stable and reliable and does what it says on the box. -Jeremy O’Donoghue

Perforce has been rock-solid for our group of ~10 developers and a codebase of 10,000+ files (text and binary), used from Linux and Windows and OS X. -Mike McNally

I can’t argue with these statements even a little bit. I believe that the Perforce server is exactly as Jeremy describes it. I give the Perforce server every benefit of the doubt, because to-date, I have seen nothing to make me believe that it isn’t a solid, and reliable, repository for your code. My complaints lie entirely with its end user tools.

You just don’t know how to use it / haven’t given it a chance / are forcing it comments:

I have been able to get up and running with no notable difficulty with Bazaar, CVS, Darcs, Git, Mercurial (Hg), and Subversion, each in under an hour using only things I could google. I have given Perforce over two months. I have talked with a number of developers around me who have been using it for years.

When I talk with experienced people the responses are either that they have no clue how to do some operation from the command line but they can in the gui, or they have a clue how to do it on the command line or gui but have absolutely no explanation for why the whack results we see. You are entirely correct when you suggest that I don’t know how to use it , but my point is that it shouldn’t take 2 months to figure out how to do basic Source Control Management operations (including branching and merging).

There is no excuse for the fact that after using it for years the people around me still can’t explain why it does some of the whack crap it does and / or don’t know how to do some of the similar operations. I would suggest to you that Perforce’s user interaction is fundamentally flawed when using it is so unintuitive that after years of using it daily many people still don’t really understand how it works or the best way to use it.

The only people who ever have any problems with it are the ones who don’t understand it and randomly try things to get it to work instead of asking for help. – Bill Napier

I don’t doubt this statement in the least. But instead of taking this as an indication of failure on the user’s part couldn’t it just as easily be considered a failure on the part of Perforce to provide its users with an intuitive interface? Perforce does not employ a paradigm that is significantly different from any other centralized Source Control Manager. As such, shouldn’t it’s general usage be fairly similar and fairly intuitive to anyone who is familiar with using them?

It sounds to me like you’re trying to use Perforce as if it were a distributed system, when it’s the opposite. I suspect many of the problems you’re having with it are a result of your attempt to use it like svn, git, or darcs. You should use a system the way it was designed to be used, and if its architecture doesn’t benefit you or help your process in any way, then you shouldn’t be using it at all. -MCS

Well, first off SVN isn’t a distributed system. With that noted, I consider Distributed Source Control Managers to be a very very recent blink in the history of computing. My first version control experiences were with CVS years ago, and later with SVN. I’m not coming to this from the perspective of some kid whose first experience with version control was with a distributed system and trying to shoehorn those ideas into a centralized system. I am very aware of the differences between them and while I was never thrilled with CVS or SVN I have no problem in using either of them. If anything Perforce should be easier for me to get my head around than any of these new-fangled distributed doodads.

I think you’re being completely unfair on Perforce. The reliability must be a configuration issue. The model is highly centralized, which sounds like it’s not what you want. -Jeremy O’Donoghue

Actually, I really don’t mind centralized systems. I just don’t prefer them. Also, reliability should never be a configuration issue. I should never be able to misconfigure a version control system in such a way as to make it unreliable. Break it sure, but if it works at all it should work reliably. If you can’t rely on your version control system then there is something horribly wrong with the system.

I find the command-line tools to be very powerful and useful. -Mark Adams

They are. I can’t deny that the command line tools are both powerful and useful. Heck, it seems as if the GUI is just running those same command-line commands under the covers for almost every operation. I also believe that the F-16 Fighter plane is a very powerful and useful but that doesn’t mean that it even remotely approaches something that is actually usable without some serious training. Unfortunately, I think the same can be said about Perforce’s command line tools (although not as much training… I hope)

So Perforce takes a different approach - try getting the hang of it before ranting so aggressively. I found it awkward too when we started using it. -i_soar\

Why do I feel like I’m the only one who sees the inherent problem with “I found it awkward too when we started using it”… No. NO NO NO. This should NEVER be uttered. Perforce has been around for over a decade, and people have been getting familiar with Source Control Managers for even longer. There is absolutely no excuse for the basic version control operations being anything other than easy at this point. Perforce has had plenty of time to refine their interface, to do crazy things like add an effing “move” command (Yes I know about the integrate command. It’s not the same thing). It’s fine to say some new, fresh out of beta tool is awkward. It’s fine to say that some tool that uses an entirely different paradigm than you’re used to is awkward. It is unacceptable for an app as old as Perforce in a paradigm as old as centralized source control management.

I agree with Perforce suckage comments:

Thanks. It’s nice to know that I’m not the only one.