Perforce Sucks

Okay, I’ve used CVS, I’ve used Subversion (command line, tortoise, svk), and I’ve just been introduced to Perforce here at NetDevil. And man, I have to say, perforce blows.

My coworker and I were trying to work on the same segment of code, separate from the trunk. So I did a little research and merged his branch into mine. Perforce died, saying I have to enable some option to do that. So I enabled the option and tried again. Perforce was obedient, and finished about 8 minutes later.

Then I looked at the changes it merged in, and they didn’t make any damn sense! It added the files that were new in his revision, but it didn’t change some of the files, and it changed some files that he didn’t change. I submitted the change before I realized this. So I set out to discover how to roll back a submitted changelist. A half hour of experimentation turned up nothing. And it’s no surprise: here are the instructions from on how to do it:

  1. Sync to the revision before the one you are rolling back
  2. Mark the changed files in your changelist for editing
  3. Add empty files for each file you deleted in your changelist
  4. Sync to the revision that you are rolling back
  5. Resolve all files in the new changelist, choosing “accept yours”
  6. Sync to HEAD
  7. Auto-resolve all files in the new changelist
  8. Delete all files you added in the changelist you are rolling back
  9. Submit the new changelist

Are you kidding?. Okay, I have to say, the svn merge syntax for doing the same thing in subversion is a little strange and hard to remember, but holy crap! At least in subversion you don’t have to manually mark/add/delete each file you changed; it does all that for you.

Oh, I suppose I should mention that the procedure given above doesn’t work.

Another issue: I have been working here for less than a week, and I think I’ve lost about three hours of development time because perforce is so slow. I think it’s probably a little faster than subversion on checkout (that is, sync). But it’s way slower for everything else. Each operation takes at least 30 seconds, and several fairly common operations (creating a new branch) can take as long as 20 minutes.


13 thoughts on “Perforce Sucks

  1. You should check out Evolution. I came across them at GDC last year and have been a HUGE fan ever since. I tell everyone I know to try it out. :) I had tried Perforce too, but I didn’t like that everything felt so command line driven. I mean come on, get with the GUI already! Even their GUI is just a mask in front the the command line.

    Anyhow, I digress. Check out Evolution, you’ll love it. It can handle huge projects no problem, has very sophisticated branching, and is build on it’s own “communications platform” so I can work from anywhere. The office, my studio at home, heck, even my local coffee shop.

  2. I’ve read at Cmcrossroads if you are doing a lot of branching or merging Accurev may be the simpler tool for your shop.

  3. Keep in mind that the speed of a tool depends on the environment into which it is installed. Perforce is a very fast tool in general. If “most operations” take 30 seconds, it is very likely an IT problem. Most operations should actually be sub-second. For instance, if SVN is installed on your local machine and you’ve put 500 files into it, it is going to be fast. On the other hand, if you have a P4 client talking to a P4 server that is 10 years old and has 100,000 changelists submitted, it might be a bit slow. But even so, 30 seconds for most operations (I assume you mean checkout of a handful of files to work on) says there is a serious issue that has nothing to do with Perforce. Ask yourself: how would they be in business if that was true in general?

  4. About it’s speed: actually found out a source of some of the problems. In my view spec I had some embedded ellipses like -//foo/bar/…/branches/…, which was slowing things down a lot. Taking out that … in the middle and just being specific about which directories I was talking about sped it up a fair amount, so that it didn’t take 30 seconds to update the view. Still, creating a branch takes way too long. Maybe I’m just spoiled by Subversion where it is an O(1) operation.

    But most of my complaints about Perforce are not its speed. I was just thinking, from a marketing point of view, Perforce and Subversion seem to be about the same: they have the same feature list. But Subversion is 100% right, and Perforce is 99% right. Perforce just has a little misconception about the role of files in version control: they are a little too special. It’s kind of file-based versioning like CVS, but not as bad as CVS. But that missing 1% has bit me over and over: it means I can’t cleanly roll back a changelist, it means I can’t branch a branch, it means I can’t have a branch and integrate from two different sources at once. Perforce is as good, perhaps a teeny bit better even, than subversion for everyday operations. But its for the very powerful once-in-a-while operations that Perfoce fails where Subversion keeps its cool. Perforce was implemented from a feature spec; Subversion was implemented from a world view spec.

    And it could be that I’m just spoiled by Subversion in everything. The more I think about it, the more I realize what an excellent piece of software it is. Not only does it handle 90% of all my version control needs, it admits the implementation of svk on top of it, which implements another 9% of all my version control needs.

  5. Luke,

    What is your need? Are you doing parallel development or collaborating with other team members? SVN doesn’t handle 90 percent of my needs.

  6. Never in all my years with Perforce have I ever encountered the slowness you speak of, or trouble merging branches.

    Furthermore, Perforce provides you plenty of protection from having to rollback a changelist. Atomic commits are there to let you make sure you don’t make the very error you made. In the last 15 years, I have professionally used and administered maybe 9 source control systems of all different types, including ClearCase, and not one of them is trivial to roll back. [caveat: I have not used AccuRev.]

    It’s funny, because your derision for Perforce is similar to mine for Subversion, which has some great features but, in the long run, seems to me to be basically a clone of CVS with half-baked directory versioning. Every shop I’ve encountered that uses svn seems to shoot itself in the foot with its implementation. That doesn’t make svn bad, but it does once again show a similarity to CVS. I have yet to see a solidly architectured Subversion or CVS implementation.

    I agree with ‘skeptic’ wholeheartedly: P4 slowness is an IT problem. I’ve never seen slow Perforce performance in my life.

    Finally, I love to live on the command line, so I may be biased, but I also am fairly fond of P4V, having used many other source control GUIs and found most of them much worse.

  7. I agree with the owner of this forum


    I never seen a so disgusting tool. ClearCase is a baby game compared to Perforce.

  8. Git > Mercurial >>>> SVN >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Perforce

  9. BTW we have a 6-dev shop. Pushing a 1-line (1-file) change in Perforce takes 29 seconds on blazingly fast state-of-the art servers. The same operation for 15+ files takes <2 sec in git.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s