The verdict on Perforce

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.

About these ads

13 Responses to The verdict on Perforce

  1. 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.

  2. Bill says:

    Found this discussion by googling, “perforce is the worst”, can’t agree more, it’s horrible.

  3. [...] current version control systems, there is lots of friction. I complained about Perforce before because of [...]

  4. Chris says:

    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.

  5. Kevin Stallard says:

    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.

    • Kevin Stallard says:

      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.

  6. LarryJones says:

    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.

    • sinnema313 says:

      Larry,

      I thought you would appreciate some advice that would make using it easier.

      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 just wanted to show that [...] Perforce does support an off-line workflow

      I’m fully aware of that. In fact, my post describes how much it sucks.

      I’d like to see any client-server system perform well under the network setup you’ve described

      My point exactly, wrong tool for the job. We should be using a distributed version control system like Git.

      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.

      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.

      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.

      Well, that’s the thing: it doesn’t in my environment. The network latency is just killing me.

  7. LarryJones says:

    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.

    • sinnema313 says:

      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

      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.

      I’ve also never found it to be slow

      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.

      If you don’t like the Eclipse integration, then don’t use it.

      By that logic I wouldn’t be using Perforce at all :P
      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.

  8. 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.

    • sinnema313 says:

      Martin,

      Would you care to write up a little something about this guerrilla Git system?

Please Join the Discussion

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 302 other followers