Why I Hate Perforce: 2. Working copy state is stored on the server

This is part of a series of articles explaining why I hate Perforce. Please see "Why I Hate Perforce: 1. The Background" first.

A working copy (client in Perforce terminology or check-out in CVS terminology) contains absolutely nothing but the files that you instructed Perforce to place there from the depot (using your client specification) and files that you caused to be placed there yourself (e.g. object files, new source files, .p4config files etc.) Perforce itself keeps no state information in your working tree (although you may choose to with .p4config files).

From some points of view this can seem like quite a good idea. Tools such as find(1) and grep(1) can't accidentally look at such data. There's no extra directories (hidden or otherwise) to confuse the uninitiated. But this information must be stored somewhere and Perforce chooses to keep it all on the server. This has a number of consequences.

The most obvious implication of keeping all the state information on the server is that if the server is down or inaccessible then you cannot perform any operations that need that state. Perforce normally marks all files as read-only until an explicit request is made to edit them. Doing this requires a connection to the server. If such a connection is unavailable then it is necessary to resort to chmod(1) or attrib to make the file writable and then remembering to run p4 diff -se when the server is available again in order to correctly mark the files as editable. Editor plug-ins that provide version information automatically for version controlled files may block for a while until they discover that the server is unavailable.

Another annoyance with keeping the state information outside the working copy is that the working copy cannot easily be moved or copied elsewhere. This might be useful due to disk space constraints, wanting to shelve some work in progress or wanting to divide current work in two. I'll come back to this topic in a later article.

The alternative is to keep the state information locally. CVS keeps all working copy state in the working copy itself. Subversion keeps that along with pristine copies of source files which allows it to only send changes when submitting files and allows diff operations without contacting the server. This means that it is possible to copy and move around CVS and Subversion working copies and the state is copied or moved at the same time. SVK keeps information in a local per-user location but does allow moves as long as you keep it informed. Distributed version control systems keep so much information that the server is only required when new changes are to be pulled from it or pushed to it.

Now read Part Three.