Dear Perforce: fuck you. August 31, 2007
[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’ve written a tool called SSCM to enable people experiencing my frustrations to work with tools we do appreciate and still keep our work synced with tools like Perforce for the benefit of our coworkers. ]
[Update 2: I’ve responded to the many comments about this here, and on Reddit Programming in a new post.]
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,
-Kate
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.
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.
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.
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.
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.
> “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