Things that annoy me about Perforce

[ewx]

Missing Features

Things that just aren't there, that shouldn't (in principle) be hard to add.

• p4 resolve won't show the difference between theirs and merged. A motivating example is where you merge from a release branch (theirs) that has changed more, and more recently, than the merge target (yours). In this case I'm more familiar with the branch changes and so would like to see what else I'm getting (i.e. from the branch I'm merging into) in the eventual submit. (Perforce have an enhancement request open for this one.)
• There is no command to report the current status of your working tree (like cvs -n up, bzr status etc). When writing VCS I had to write my own. p4 opened is part way there in that it will tell you what have open, but the output format is rather verbose; it lacks the equivalent of .cvsignore; and it doesn't tell you if any files need resolving.
• p4 diff (etc.) won't do the equivalent of diff -N (even if you set P4DIFF!). This makes the patches they generate incomplete if there are any added, branched or removed files, which is inconvenient for review and means that they're not suitable for use with the patch program.

Interface Inconveniences

Nuisances in the user interface. Again, I don't think these would be especially difficult to change.

• Perforce forms (e.g. for p4 submit) treat visually identical whitespace as distinct. So if you've configured your editor not to insert raw tab characters (because your coding standard says you shouldn't use them, for instance, which is quite sensible given the trouble they cause) then your change description will appear to be correctly formatted when you submit it but be wrongly indented when you look at it in p4 changes or whatever.
• p4 submit can only take one filename pattern. i.e. “p4 submit one.c” is OK but “p4 submit one.c two.c” is not; you have to manually add files to a change in separate steps before submitting it, or construct a change listing all the desired files manually.
• If a change cannot be submitted you have to modify it and resubmit it; you can't delete it and start again, which otherwise might well be more convenient. The restriction seems to be an entirely bureaucratic one, too: you can remove all the files from it and then delete it. (For non-p4 users, the “change” here means the description and metadata, which in p4 have an independent life of their own; not your edits.)
• Output tends to hide important information among unimportant. For example if a p4 sync updates 100 files and only one of them requires resolving, you're likely to miss it. Summarizing the files that need resolving at the end of the list of updates files would improve matters.

Model Problems

Flaws that result from some aspect of the system's design. These might well be difficult to change. (Which doesn't make them invalid; if the underlying design of a system doesn't support useful features, then perhaps that design is itself wrong.)

• There's no whole-module graphical branch history view (like gitk or bzr visualise). p4v will show you a per-file branch diagram but nothing better than that.
• p4 describe and p4 diff2 don't honor P4DIFF (because they do the diffing on the server), so if you have a better diff tool than p4's built-in one (which I do) then you don't get the benefit of it.
• Execute bits are not properly versioned. You can't just edit a file and chmod it, you have to use a special command to change the execute bit. That's just inconvenient, but worse is that integration (merging) doesn't copy the change, so you have to change it on every branch separately. (Updated in the light of comments: apparently there's an option to do this, but, bafflingly, it's off by default.)
• If the server is running slow or is down, all operations that are in any way related to version control are affected. Since there is no client-side state or caching other than file contents, this includes non-mutating operations (diff, history, etc; even testing whether a file is in version control).
• P4 doesn’t merge renames correctly. Instead when you merge a rename operation, it deletes the rename source in the destination branch and copies the source branch’s version of the renamed file(s). You have to manually re-do the rename every time you merge across it - expensive if you are in a branch-heavy environment.

(Yes, some of these problems exist to some extent in some other version control systems too. That doesn't mean they're not annoying...)
Things that aren't annoying

• The need to p4 edit isn't a big problem in practice (even though it sounds like a nuisance if you're not used to it), given adequate editor integration.
• It doesn't crash. As a rule the problems seem to be design flaws (such as those above) rather than implementation bugs.
• It's usually fast.