Perforce, or P4, is one of the better centralised version control systems (VCS) out there. I worked with it during my 4.5 years at Symbian, and it was bearable, although by the end of my tenure it started creaking at the seams, becoming very slow and often going down under the motherload of code we were pushing into it (we were about to release Symbian OS 9.1 — remember that? Thought so.)
Now I have to work with Perforce again at a client site. Back at Symbian I didn’t know any better, having had a little prior experience with Visual SourceSafe (luckily it was short so I didn’t get scarred for the rest of my life). Naturally, after VSS I thought Perforce was the bee’s knees. (A set of punch cards looks like a decent version control system compared with VSS.)
Nowadays I tend to use Git everywhere I can, including my personal projects. Having experienced such an amazingly powerful distributed VCS (DVCS), I feed awkward in P4. Don’t get me wrong, P4 is still a very powerful VCS that is, IMHO, miles better than ClearCase or Subversion. It gives corporate users and their superiors peace of mind, being enterprisey and centralised and all. It runs great on UNIX and Windows and is probably even scalable, if you know what you’re doing. I’m not talking about the costs here, I imagine for big firms it’s not an issue (and you can run 2-user server free of charge if you are feeling masochistic).
What bugs me is how P4 is used, or abused, by developers, and how inflexible and cumbersome it can be if you don’t know what you are doing.
Awkward branching
As far as I can recall, Perforce branches are just directories, like in Subversion. To set up a branch, you need to create a branchspec and then map it into your client view, and then sync files to it so that your branch has physical representation in your file system. After git checkout -b my-branch this looks very tedious. Developers tend to avoid the hassle and work directly on the mainline. The result is a complete mess of a history, with thousands small changes scattered around.
Poor tool support
“What?!” — you exclaim, — “Perforce is supported by everything!” True, kind of. Take Visual Studio, for example. Working with P4 directly from VS looks very convenient. Until you hit one of the trickier situations, and then you realise that using integrated VCS support in Visual Studio is crazy. It is so totally broken, it screws with your mind, hiding the actual workings of Perforce from you until you’re so deep in it there is no way out.
With Git, you use git status to see what is happening to your working copy (and the index, which is an amazingly powerful feature absent in P4). VS has this “Pending checkouts” view which would have been useful if it weren’t so damn slow. Also, there is context VCS menu in the Solution view which 9-to-5 developers tend to use, screwing up everything.
Most 9-to-5 developers don’t care. They especially don’t care about their colleagues that are working in the same codeline. So they check out files and code away, and then they get the latest changes (which is, by the way, at the top of the menu in the visual clients), and they continue coding away and then they submit their changes. And by doing that they overwrite the changes to the same files their colleague just submitted. Why? Because they should have used Integrate instead of Get Latest Version, as the latter skips files they have checked out, whereas the former actually merges changes in the repository with the current changes in the working directory.
Or you added a file and then submitted just a part of your project using the context menu. The build is now broken because the P4 plugin decided to not commit the file you just added.
Or there’s another good one: P4 VS plugin does not merge project files. Come on, they are just text files, what is so special about them? No, it says. You have local modifications, and the project was also modified in the repository, so now you have to choose one or another. Or click Cancel for a random choice.
Conclusion: do not use the VS integrated P4 support if you value your time and time of your colleagues. Use the P4V visual or command-line client.
Slow speed
P4 being centralised VCS, it is a given. Still, after seeing how fast Git is, P4 can be unbearably slow.
Luckily, with the help of the Internet I figured out how to use Git on top of P4 for added easy branching, unsurpassed flexibility and speed, and smart merging, so that nobody notices it. I’ll explain it in the next post.
