Commavee

Two of my recent clients use Perforce. In the ten years I’ve done build & release management, this is the first (and second) time I’ve ever used Perforce. Here’s what I like - and don’t like about it.

First, the whole concept of the depot is nice. Perhaps its similarity to a CVS module makes it appealing, but it does seem natural to view the repository this way. I like this.

I don’t like the notion of checking out files before I can edit them. Realizing that may sound silly to someone who’s never used CVS, consider this: with CVS, you check files out *once*. From that initial checkout, every file is a candidate new revision at all times. This gives me freedom to experiment and make commits at a frequency that works for me.

With Perforce, I must expressly checkout a file I wish to edit. This locks it (apparently) from other users, so unless I’ve missed a key point Perforce isn’t going to fully support concurrent development. I don’t like that. I also don’t like that I must *think* about checking out a file before I edit it. This doesn’t seem natural.

I also really dislike the client spec. This is a rule, similar to Clearcase’s config spec, that “selects” sets of file revisions and makes them visible to you in your file system. This level of abstraction has the advantage of masking versions - and whole file structures - from those who have no need to see them, and may damage them if they did have access to them. But it has the disadvantage of masking *everything* that isn’t selected by the client spec, making setting up new environments incredily tedious.

I spent three or four days - with hands-on, heads-down help from one of the senior engineers - setting up a build environment at my current client’s shop. No one - let me repeat that - No One - knew what the client spec should be, so we tuned it the best we could, tried a build… and it failed… and then repeated this process over three or four days til we got it right. What an incredible waste of time.

In CVS-land, you would:

1) ask what branch the build lived on
2) checkout that branch
3) execute the build

Even if no one actually *knew* the answer to Question 1), you could query CVS for all known tags (branch and release) and at least have a list from which you could choose. Practically speaking though, everyone working on that project in CVS will *know* the branch context because they will have it checked out.

I read lots of comments about what’s great with Perforce (atomic commits, etc.) but no one seems to talk about these issues that I encountered trying to doing simple things. Granted, once the client spec is correct, Perforce functions as expected. I suppose its accurate to say that Perforce functions as expected when you have the client spec set incorrectly as well… it just shouldn’t be so difficult to see release tags in Perforce.