»
S
I
D
E
B
A
R
«
Dear Perforce: fuck you.
August 31st, 2007 by masukomi

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).]

[Update 2] I’ve responded to the many comments about this that were left here, and on Reddit Programming in a new post.


19 Responses  
  • masukomi writes:
    March 11th, 2008 at 4:10 pm

    There used to be a bunch of comments here. The general idea was that if i just spent a few months getting used to it, or read a big ass book on it, it would all make sense. I countered something to the effect that both of those suggestions meant that Perforce had failed the usability test miserably. Many felt I was just stupid. *shrug*

    Then I upgraded to a new blog engine and didn’t bother to bring over any comments, at all. So all of this is lost… alas.

  • nobody writes:
    March 18th, 2008 at 2:50 am

    I’ve never had any of these problems with p4, and the command-line client was incredibly intuitive for me. I don’t know what you’re doing wrong, but you apparently have fundamental misunderstandings about Perforce. svn stole all its good ideas from Perforce (and implemented them slowly and poorly–hope you only ever want merge changes between a branch and the trunk once), and saying you’d rather use CVS over just about anything else is simply absurd.

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

    This can’t possibly happen. “I submitted a file, and it’s magically rolled back to a previous version.” Maybe you synced a previous version? Maybe the submit wasn’t actually successful?

    # 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).

    You can sync -f specific files or directories, except that this shouldn’t be happening anyway unless you’re doing something wrong.

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

    “Their” changes exist because Perforce thinks you have previous versions of files (because, apparently, you do). p4 will ask you to resolve changes if you try to submit with a previous version synced. Rolling back is implemented as p4 sync @previousrev; p4 submit; p4 resolve -at; p4 submit -c thechange–so this makes sense. Perhaps “yours/theirs” is bad terminology on their part, but it’s not hard to understand.

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

    I don’t even understand what you’re trying to say here. p4 will allow you to automatically merge any non-conflicting sections, accept all the changes you’ve made (i.e. copy the file), ignore all the changes made (use “their” file–basically don’t do the integrate), or do a manual merge (only usually needed for conflicts).

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

    Subversion will do the same thing with regard to line endings if you ask it to. If you don’t like it, turn it off. I don’t know of any version control system that will store exact file permissions other than an execute bit, so your complaint doesn’t really make a lot of sense. Getting used to p4 edit is a little weird, but it has advantages (see below); the -w/+w stuff is simply to remind you to do it. Besides, there’s always the “allwrite” client option (you’ll still have to mark things as edited somehow, but again, see below).

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

    I’ve never even used P4V, and I have no problems, but this is a matter of opinion.

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

    p4 diff -se will help you find these. You can even use p4 like CVS with this (i.e. find files that have changed for p4 edit instead of telling it first, but then you circumvent the entire reason p4 edit is good: by avoiding the need to diff every file. This matters a *lot* in huge trees–if you aren’t working with them, p4 edit can seem stupid.)

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

    Again, I don’t know what you’re doing, but I’ve never seen anything like this.

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

    I’m not sure anyone uses *any* version control system with “terabytes” of data, but p4 certainly scales the best of all centralized version control systems.

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

    Read this: http://kb.perforce.com/UserTasks/WorkingDisconnected

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

    Again, I haven’t seen this.

    I don’t work for Perforce, but I like it a lot, and if you understand its idiosyncracies, it’s about as good as centralized SCM gets.

  • Draco writes:
    March 30th, 2008 at 4:11 pm

    I agree with your sentiment 100%.
    Perforce sucks.
    I would take plain primitive RCS over it any day.

    Perforce software is not worth the CDs its printed on.

    Given that awesome alternatives are free, and it costs developer time to have problems with your change management system.

    I would estimate Perforce at most -$20,000.

  • Kocka writes:
    May 20th, 2008 at 10:38 am

    Completely agree!

    Perforce is a pile of crap for a lot of money. It is to kill time. I am happy to help my employer move to SVN from this crap.

  • Steve writes:
    June 26th, 2008 at 7:55 pm

    Wow, what a heap of bile and vitriol. Yes, I would probably prefer to use Mercurial or Git instead, but SVN/CVS? Are you joking??

    The OP and other commenters who want to use SVN or CVS are completely missing the point. As “nobody” implies, what Perforce does well is merge changes between branches, and keep track of it. What SVN and CVS have in this area is an utter joke and completely unusable for any real software development project.

    SVN and CVS are toy version control systems, suitable only if you never branch your code, and how many people can really say that with a straight face. Makes one wonder what kinds of projects these people who want to use SVN/CVS are actually working on.

    Sure, Perforce has some usability issues. The thing about having to “p4 edit” a file before you work on it is annoying but whatever. It happened to me once, I figured out how to deal with it, and it never bothered me since. I’ve never had my client get out of sync.

    The p4 command-line client is very well done and highly scriptable. The comment about having to use the GUI to get real work done is ridiculous — the command line client is faster and better for everything, and VCS-intensive work such as merging can only be done sanely on the command line.

  • Andrew writes:
    July 18th, 2008 at 8:56 am

    > “p4 edit” a file before you work on it is annoying but whatever

    I have to do this *tens of times per fucking day*

    USING PERFORCE SLOWS ME DOWN A GREAT DEAL!!!!

    thanks for the blog entry, at least I know there are other people out there with self-respect and decency

  • JonR writes:
    July 31st, 2008 at 8:21 am

    i’m googling “perforce is shit” instead of doing actual work. because perforce is shit.

  • BPC writes:
    August 25th, 2008 at 6:43 pm

    Wow … lots emotion … I know it can require a bit of extra effort … try making the default types for the files to be +w then you can always edit the files without checking them in. Yeah having to check things in can slow you down but working with the alternatives may be worse.

  • Mark writes:
    August 29th, 2008 at 9:31 am

    As a non-programmer, my main gripe is with the P4V interface…actually all of the Perforce GUI clients. Compared to tortoisesvn (a FREE product) they’re utter rubbish.

    Since moving from SVN to Perforce, we have the whole team complaining about missed files, read-only attributes & lost productivity.

  • Marc writes:
    September 13th, 2008 at 5:04 am

    I have used several version systems in the past (CVS, SVN, GIT) and I can honestly say that Perforce is shit on so many levels. Name a program that consumes 16 GB of memory on start up.

    (Note: this should happen on UNIX)

    My company pays dearly for this overpriced piece of crap. An absolute waste of money and productivity. I look forward to the day I have finally migrated all of our users to Subversion.

    FUCK YOU Perforce!!!!

  • m writes:
    September 16th, 2008 at 11:37 pm

    “Telling perforce to sync it just results in it telling me it *is* in sync.” // “This can’t possibly happen” => Bullsh*t. It can, it has, it does. I don’t know what env you’re in, but it happens. Maybe you’re in a total homogenous environment, single version of p4/p4v clients, single user, ? but trust me: it happens.

    Perforce has been around forever and a half, and only maybe now they’ll start making it usable, due to truly serious competitors out there (not just svn, but hg, bzr, git, …), mostly in the distributed realm. It’s easier to imitate than innovate. But I’m sure they’ll fuck it up just to make the tool look complicated enough to bewilder the corporate-types who buy this shit.

    It wasn’ t mentioned, but just try refactoring c++ or java code in an IDE using perforce. There’s no (or little) support for p4 in IDE’s since…well, who’d want to map this interface onto logical SCM actions. To rename a Java class I (1) do it in the IDE, just as a “preview” (2) get a list of filenames changed, (3) UNDO the change in the ide (cancel the refactoring), (4) write an insane shell script that does a rename in perforce, (5) do the refactoring, (6) copy all the old files back (script), (7) do the p4 changes.

    Perforce is very, very manually intensive; I’ve got p4 shell scripts I can use on un*x, but on windows p4 acts differently & you’ve got to use p4v. I submit & switch platforms just to do certain p4 tasks. Perforce is the bane of my professional existence. I do personal projects at work just using svn (and/or hg) and merge it in the “official” p4 repo just for posterity, AFTER the work’s done. (I’d like to look into tailor, as a possibility to help out with this…..)

    Perforce, f*ck you from me, too. I’m just insulted that my company thinks this is a good thing. No, I don’t need to read a book; the people who use & like perforce need to use & learn another system to compare it to, or need to actually use perforce themselves.

  • jonno writes:
    November 6th, 2008 at 10:12 pm

    It sounds like you have more than one clientspec pointing to the same local file structure. Maybe you’re submitting with one clientspec and sync-ing with the other? (Entirely possible if you’re using scripts.)

  • Mishets writes:
    November 24th, 2008 at 11:34 am

    I have to admit – I’ve found this page having typed “perforce is shit”. With all my tolerance I say this piece of shite really takes the biscuit.
    It’s impossible to get stuff checked out to the different location. It’s countless the number of times you get meaningless error messages with the perforce MSVC plugin and fix bindings. For fuck’s sake why do I have to set the flag “forced sync” every time the file is missing while syncing.

    We got a file deleted this June. Another file with the same name happened to come up last week. And got automatically deleted by perforce again at the integration stage. Outrageous at its mildest.

  • Bryan Ischo writes:
    July 2nd, 2009 at 9:48 pm

    Perforce isn’t perfect, but it’s not bad. I’ve never had any of the “problems” you’ve had (which I suspect are just user errors) and most of your rant amounts to “wah, it doesn’t do things exactly how I want, even though what I want is dumb”.

    You may think that having to forcefully tell Perforce what files you want to edit is a drawback, but it actually enables Perforce to not have to scan your entire tree to see what files are opened/modified in order to know what you’ve changed. When you have tens of thousands or hundreds of thousands of files in your Perforce tree, this is a MAJOR performance win.

    Sorry to have to say it, because generally I agree with rants about useability but … in this case, you’re mostly just retarded. The tool is fine, learn how to use it (which really isn’t that hard at all) and you will not have any problems.

  • masukomi writes:
    July 3rd, 2009 at 8:55 am

    Yes, they were most likely user error because it’s human interface is totally unintuitive and crap. Your comment about the performance win is provably false because I don’t have to tell git what files i’m going to edit and it’s notably faster than perforce.

    The problem with the sentiment of “learn how to use it” is that Perforce does such a horrible job of making it easy to learn. The commands aren’t intuitive, you never have a clue what they’re going to call something or where to look for instructions on how to do the thing you need to do (because you can’t figure what it’s called) and you pretty much have to read a book to really get a decent understanding of it. This is total failure of their human interface. Simple example: most of the time “…” is a file path wildcard (totally atypical) but sometimes it’s “*” and when you use “…” instead of “*” it tells you you should use “*” instead, when it could just @#$% accept the “…” since it knows what you wanted!

  • Alex Chu writes:
    July 7th, 2009 at 10:12 am

    I hate perforce as much as you did (I think). Today it did me another trick. I use p4v to add a whole directory of source files in two different places, and found the number of files added differ by one! After checking the opened file list, I found one file is missing from one of the two add operation. The two directories added are exactly the same and there is no link in them (all ordinary files and directories). Just amazing!

  • Shredder writes:
    July 22nd, 2009 at 3:45 pm

    What a soothing post I’ve found after hours trying to submit about 9000 files into perforce but only to get the error “Some file(s) could not be transferred from client”, with no useful hint which files are causing the problem!

    Perforce is so stupid! It’s company should pay me a lot of money for using it!

    Thanks a lot for this post!

  • Ben writes:
    August 19th, 2009 at 5:50 pm

    To people saying perforce’s branch tracking is better than SVN’s: hahahahahaha.

    This might be true if you compare to old versions of SVN, but is no longer true. Even if it were, I’d take SVN’s branches over perforce’s any day, as branching in perforce is a major thing that is easy to get wrong, and thus you can’t use for anything but major projects. With SVN you can do all kinds of nice things (mostly which approximate a DVCS) like make a branch for every non-trivial set of changes. In perforce, no way in hell.

  • Nathan writes:
    January 5th, 2010 at 4:56 pm

    The saddest thing about Perforce is that it has changed very, very little since I started using it 10 years ago. In that same time we’ve seen an explosion of SCM systems, nearly all of which are better than Perforce in most every way. I implemented much of the SCM support in Project Kenai so I feel I have a well formed opinion in this matter, having integrated both Subversion and Mercurial into the system. Unfortunately I’m now working at a place that has been using Perforce extensively for nearly 10 years so there’s little hope of migrating.


Leave a Reply

»  Substance: WordPress   »  Style: Ahren Ahimsa
© Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.