Why (Not) Perforce

Jim Correia writes:

So I’m watching the video from Evening at Adler.

I’ve have direct experience with Projector, CVS, Subversion and Perforce. (I haven’t used any of the Microsoft stuff.)

So what are your gripes against Perforce?

I triedtotalkreallyquickly that evening. I was banking on the idea that the audience would still just be able to make out what I was saying, but the lossy audio codec would throw away the crucial bits that straddle the line between sage discussion and incomprehensibility.

Somehow Jim managed to reconstruct and decipher what the heck I was talking about, and one of those points was trashing Perforce. Specifically, when an audience member asked for version control recommendations, I offered a Perforce anti-recommendation.

I have two issues with Perforce: its lock-modify-unlock usage model and its utter reliance on the network.

Once you’ve used the copy-modify-merge solution offered by CVS and Subversion, it’s really hard to go back. I much prefer to have a personal sandbox of source code that I can tear through and then ask the SCM what I’ve changed (to weigh for the final commit). Contrast to lock-modify-unlock’s constant “Mother, may I?” where you have to explicitly unlock files as you edit them. Yes, tools can help with the burden (Both BBEdit and Xcode offer Perforce support), but I’m of the opinion it’s wholly unnecessary from the start.

Perforce’s attempts to enforce lock-modify-unlock by clearing the three write bits (user, group, other) for files upon checkout. However, p4 (the command-line Perforce client) appears unwilling to flip those bits back. This leads to a situation where you complete a feature by committing to a brach, but p4 lacks write permissions to delete files that are in the way. The solution? As far as I can tell, run p4 as root. It scares the hell out of me that I need to run a command line tool as root just to commit code.

The lock-modify-unlock model also assumes consistent, near real-time communication with the server. Good luck getting work on a plane, train or conference with unreliable wifi. Even if you’re lucky enough to work at home, it can be double-plus fun when it forces constant tangling with sadistic VPN client software. You can’t even access p4’s help without a live connection to the server!

Yes, you can use Perforce in a disconnected manner. This is how I use Perforce. However, you’re completely brow-beating the system at this point. All claims of speed fly out the window. Perforce is not designed to operate offline, and using it like this means a full network-copy of each and every file in your entire source tree for each and every sync and commit. Personally, it takes me ~10 minutes to commit a one-line fix to a 43MB source tree over a VPN — and it’s getting worse.

I’m considering writing a Subversion front-end to p4, where the p4 workspace is mirrored into a svn workspace. It would allow me to work that way I want, and should dramatically increase network efficiency and thus commit times. I hope that fact that I’m contemplating writing such a tool illustrates my profound disappointment in Perforce.

Could Perforce ever be the “right” choice when picking a SCM? Sure. If all your developers are always physically present on-site and you’re dealing with 500K+ source files, Perforce makes sense (or if you’re dealing with a smaller number of much larger files). Recognize however, this is the uncommon case. I venture to say many Perforce shops would be better served by Subversion.

Wednesday, November 16, 2005
12:14 PM