This note gives a rough comparison of PERFORCE with ClearCase. We obviously can't claim being impartial, but this does shed light on the PERFORCE approach.
The raw data for these astonishing results are available for scrutiny. The conclusions are as follows:
In contrast, PERFORCE populates a regular filesystem with copies of files from the repository. PERFORCE uses centralized metadata to manage the local files, and on request synchronizes the local copies with the repository or submits new changes to the repository. Aside from explicit PERFORCE actions, the client workspace can be treated like plain old files. Editing and compiling happen at the speed of user's local, fast disks.
PERFORCE uses a thin protocol between the client and server, and only transfers files over the network to populate the client or submit changes to the repository. Most of a user's work - editing, compiling, etc - are against the local client filesystem. (This filesystem could be NFS mounted as well, but it is not required to be.) PERFORCE can serve many, many users before being saturated, because the users only need to make seldom requests to the PERFORCE server and PERFORCE answers these requests quickly.
PERFORCE meets the build system only at the source code interface: PERFORCE specializes in reproducibly delivering source code. Even if you repopulate your client with source code from a year ago, PERFORCE updates the filesystem timestamps so that any normal make(1) program can figure out what to do.
PERFORCE puts all metadata into a single, low-maintenance, high-performance database. PERFORCE can reproduce information very quickly.
PERFORCE can checkpoint its database quickly (on the order of 3000 files a minute). During this time PERFORCE holds itself offline, but afterwards the repository can be archived while PERFORCE is back online. This works because the PERFORCE file store is grow-only, and all the dynamic data is captured in the checkpoint. Further, even when PERFORCE is offline users still have access to their files (because the files are on their local disks) - they just can't get to PERFORCE for a few minutes.
The predecessor to PERFORCE the internal SCM system used at Ingres corporation called Piccolo, had one administrator for over 250 users. PERFORCE is smaller and about 10 times faster than Piccolo, and consequently easier still to administer.
PERFORCE's licensing registers and counts users statically the first time they access the repository server. This is simple, easily understood, does not impede performance and requires no administration. There is no license manager daemon to have to contend with. Once a user is registered they are guaranteed access to the server at all times, so no one has to worry about denial of service at a critical time. And it is trivial to workaround the licensing in case you need to provide access to a new user in a pinch. PERFORCE's primary goal is to get things done, not get in the way.
ClearCase allows you to change files in groups, but doesn't remember that they belonged as part of the same change. Just about every company that has purchased ClearCase has had to write wrappers to introduce the notion of a "change." But these wrappers can't guarantee atomicity of a change: if a change submission gets interrupted, the ClearCase VOB can be left with an inconsistent set of files.
ClearCase presumably knows what files a client has, what files are being worked on, what integrations have been made, etc., but it doesn't present it in any way that allows the user to manage his/her work. With ClearCase, users must resort to "Postit-Note" SCM.
ClearCase can only run on platforms where it can live in the filesystem, leaving many variants of UNIX and other OS's out in the cold.
PERFORCE uses a branching model called Inter-File Branching TM: the branch name is an arbitrary part of the file name, while version numbers remain integers (1..n). For example //depot/r1.1/project/foo.c might refer to the file project/foo.c in the r1.1 branch. Branch namespace is mingled with file namespace, creating a single hierarchical namespace for the user to slice as desired.
PERFORCE's advanced branching model opens the door to new, efficient styles of software development process. (You can read about this in PERFORCE Software Life-Cycle Modelling.)
PERFORCE assiduously tracks what files were branched from other files, and what integrations have been made among them. It can quickly tell you what hasn't been integrated, and can then step you through the integration process. When integrating, PERFORCE runs the components through a three-way merge program, but it also recognises certain types of integrations as attempts to get divergent code lines back in sync, and uses that information to make subsequent integrations even easier.
As a result, PERFORCE can easily manage parallel lines where changes are being propagated in both directions.
PERFORCE uses views to select what files a client wants and (optionally) how the files should be named on the client. But because PERFORCE handles branching in the file namespace rather than in the version namespace, PERFORCE views don't need to include a version selection. This simplifications means that ordinary users can configure their views with a fair chance of getting it right. Because the "branch" of a file appears in its name, users are continually reminded whether they are working on the right files or not. This makes it easy for users to "do the right thing."
If you want to see what another competitor thinks of ClearCase, check out Continuus/CM's response to an Atria bash on Continuus' Web site. It's hard to tell who wins this mud-slinging contest, but they both get pretty dirty.