Comparison of Version Control Tools

Summary

	ClearCase (basic)	ClearCase (extended)	Perforce	Subversion
Site Setup	hard	hard	easy	medium
User Setup	hard	easy	easy	easy
Atomic Change Sets	no	yes	yes	yes
Branching	chaotic	easy	easy	easy
Merging	hard	easy	medium	hard
Labeling	slow	fast	fast	fast
Refactoring	easy		medium	medium
Remote Users	snapshot views		medium	easy
Distributed Development	multisite		proxy, manual sync	proxy, manual sync
Extendability	triggers file types file managers		triggers	open source
Windows/Linux	works	hard	works	works

Details

Site Setup

Site setup is about preparing the hardware, installing and configuring the software.

Even though installing ClearCase itself is fairly straightforward, planning for proper resources and assigning the correct hardware to the various services requires an experienced ClearCase admin. The biggest problem is that once assigned, changing your mind about the location of resources is expensive both in time and effort, so you better get it right the first time.

Installing ClearCase on Linux platforms is complicated by the fact that the MVFS system module is not available in source form, so will only work for very specific sets of major/minor kernel versions. This may hamper installation of kernel security patches and other enhancements and upgrades.

ClearCase's nature stresses network infrastructure. User experience will be in direct proportion to your expertise and cunning in setting up the appropriate backbone and switches.

Recent versions of ClearCase have removed a variety of limitations on vob size and total size of database files, so the problem of partitioning your source code repository has been simplified to some extent. Access control and network load management are still issues, as are high availability scenarios.

ClearCase (extension)

Adding the extension pack is fairly straightforward, but some add-ons are hard to install - for example the keyword expansion file type manager.

Perforce

Perforce is famously easy to install. One statically linked binary, a startup/shutdown script and adequate disk space for the repository are all you need. For large scale distributed environments, a p4 proxy is available, again trivial to install.

Subversion

Depending on the format of the distribution and the platform, this may be anywhere between easy and hard. A lot depends on the level of paranoia in the install.

User Setup

The user setup describes the difficulty of getting users to use the version control system.

ClearCase (basic)

ClearCase in its basic form is more a version control development kit than a fully grown system. Lots of capabilities, but no clear pattern on how to use them. Therefore, a lot of coordination is required to agree on conventions and patterns.

ClearCase (extension)

The purpose of the extension pack is to provide ready-to-use patterns. User setup is vastly simplified.

Perforce

Perforce has a straight-forward usage pattern for developers with very little need for customization.

Subversion

Subversion shows its roots in the CVS system it is replacing, but the patterns are usable and do not need much customization.

Atomic Change Sets

Atomic change sets reflect the fact that a logical change rarely affects just a single file.

ClearCase (basic)

Again, Clearcase's toolkit nature manifests itself. There are many choices one can make about how changes are to be made, and grouping changes into atomic change sets is not one of them.

ClearCase (extension)

The extension pack implements atomic changesets. This turned out to be surprisingly hard to do correctly. The absense of an atomic test_and_set_lock operation required a fragile workaround.

Perforce

Atomic change sets are an integral part of the design, to the point where file specific checkin comments are not possible.

Subversion

Considering that Subversion's goal was to fix all major CVS flaws, one is not surprised to see atomic change sets here.

Branching

Considered here are both the ease of creating branches and the efficiency and correctness of the branching model.

ClearCase (basic)

Once again, the toolkit nature of ClearCase provides many ways to accompilish branching. There are strong hints on how it should be done, but you have all the freedom to shoot yourself in the foot. It is interesting to see how the Unified Change Model (UCM) hacks around the original intent of the ClearCase design, without really creating a workable solution.

The good news is that the GUI's version tree browser is an extremely powerful tool as long as branching is performed as the designers hinted.

ClearCase (extension)

The extension pack implements cheap branching and hides the associated config spec hackery to make it work. Nevertheless, the ClearCase branching model has a fundamental limitation: the branch cascade must be of constant depth, since branches are implemented as subdirectories in the version extended filesystem space. This renders the following branching strategy impossible to implement in ClearCase:

     __________________________release 1
       \__________________________release 2
          \__________________________release 3
             \__________________________release 4
                \__________________________release 5
                   \___...

Perforce

Perforce implements a "branching by copying" model. This makes branches and subdirectories indistinguishable within the repository, and therefore requires site specific conventions to be defined and documented. Perforce provides some relief by encouraging people to register the mappings between the parent and the child branch in a so-called branch spec. More on this in the refactoring section.

The biggest drawback of the "branching by copying" model is that usually, the whole tree will be copied, and therefore every file will appear as having changed when in fact, it hasn't. Perforce's version tree browser is practically useless, since almost all the version trees will look like stars: a trunc version in the middle and a gazillion branches with no addtional revisions.

Another issue concerns client filesystem space. Yes, the server implements a copy on write model, so branches are cheap on the server side, but not on the client side. Yes, disk space is cheap, but when you run out it is still a nuisance - and run out you will.

Subversion

Subversion's branching model is almost identical with Perforce's model, except that there is no way at all to record the mappings. Users are expected to do this themselves, either by following site wide conventions or by writing shell scripts which define the mappings. More about this in the refactoring section.

Merging

The ease of merging is the true litmus test of a version control system.

ClearCase (basic)

ClearCase's findmerge command epitomizes the toolkit nature. One piece of good news: since branches are implemented within the version extended filesystem space, there is no confusion between relocations and branches. The bad news is that writing correct and efficient findmerge queries is a true art form.

ClearCase's directory versioning and branching takes a little effort to grasp, but is extremely powerful. More about this in the refactoring section.

ClearCase supports "transitive merges". Merges do not have to be along branch arcs, but can be between any two versions, as long as it is possible to locate a common ancestor within the version tree.

ClearCase's merge tool itself is exemplary and should be held up as a model for the other systems compared here.

The existense of selective and subtractive merges makes writing redo and undo tools possible

ClearCase (extension)

The extension pack wraps around findmerge, using a query that took about a year of tweaking to get right. With it, the user level experience is almost identical to the user experience in Perforce.

Perforce

Since perforce encourages the use of branch specs to define the mappings between the parent and the child branch, merging between the two is straightforward. Note that branch specs and branches have nothing to do with each other, and that it is possible to write a branch spec which merges between distant relatives - as long as it is possible to locate a common ancestor, the merge will work.

Subversion

This is the place where Subversion falls short. It is the job of the user to track the genesis of a branch and to issue the specific merge commands needed for reconciliation. In the simple cases, this is not such a burden, but once the mappings contain some source tree changes, issues will arise and require users to maintain shell scripts to execute the merges correctly. More on this in the refactoring section.

Labeling

At this day and age, Labeling (or tagging) is overrated. One direct consequence of having atomic change sets is that there is a change number associated with every state of the whole source tree, as it existed in time. Yes, some people wish to play games by mixing and matching various versions of subtrees, but doing this on a regular basis is not recommended, because it makes it very hard to create patches from releases generated in that manner. People who wish to mix and match should use branches instead of labels.

ClearCase (basic)

Labeling is where ClearCase shows its age. Back then, people were obsessed with "locking down baselines", and unfortunately, this obsession is still very present in the unified change model (UCM). The single largest drawback of labeling in ClearCase is that it is slow and non-atomic - which leads to the chicken and egg problem: why label if you already have a way to specify the versions uniquely (usually via a time rule) - or rather: how can you label if you can't specify what you are labeling?

ClearCase (extension)

The extension pack does not use labels at all. It uses time rules and a so called "canary bird element" which gets checked out and checked in every time a developer submits an atomic change set. This one element essentially has the complete version tree of the whole repository embedded - and if people wish to label that, more power to them - and that will generate a time stamp that can be used to select the correct revisions in the remainder of the source tree.

Perforce

Perforces procedure for attaching labels encourages good practice by forcing the user to assemble a client tree first. Nevertheless, it is not recommended to use labels for more than a synonym for change numbers. To mix and match, use branches right off the bat.

Subversion

Subversion does this right. Labels and branches are the same thing, so no choices - which is a good thing.

Refactoring

Refactoring code often and early has been recognized as a crucial activity in agile development. Any systemic impediments to this process should be removed. Unfortunately, both version control and build systems have not been very helpful in this regard, which is why this site exists in the first place.

ClearCase (basic)

ClearCase clearly has the lead here. The identity of files and directories is not tied to their location in the source tree, and can therefore be moved around at will. The formulation of proper findmerge queries to correctly merge a sustaining development (aka patch branch) with a refactored branch is tricky, but doable, and does not require developers to keep track of where things moved.

ClearCase (extension)

The extension pack neatly wraps around the findmerge problem and provides the correct implementation. Simply create a new branch, reshuffle at will and maintain continuity with the old world with no hassle. ClearCase has and maintains the lead here.

Perforce

In Perforce, a relocation is a copy and a delete. The proper way to implement refactoring in perforce is to create a branch spec which maps the old tree into a new tree, making the relocations explicit. For example, suppose you have the following project:

  //depot/v1/project/README
  //depot/v1/project/main.c
  //depot/v1/project/module1.c
  //depot/v1/project/module1.h
  //depot/v1/project/module2.c
  //depot/v1/project/module2.h

Now, let's assume we wanted to split this into a library, and separate the header files from the implementation files (not a good idea, but unfortunately common). The best way to go about this is to create a new branch and use a branch spec to map the old location to the new location:

  //depot/v1/project/...        //depot/v2/project/main/...
 -//depot/v1/project/module*    //depot/v2/project/main/module*
  //depot/v1/project/module*.h  //depot/v2/project/lib/incl/module*.h
  //depot/v1/project/module*.c  //depot/v2/project/lib/impl/module*.c

Note Perforce's typical "I want this, but not that, but this instead" idiom of constructing these mappings.

This works nicely as long as you do not need to merge back into //depot/v1. If you use a trunc/branch strategy, then you need to remember to delete the old code when merging back. You may wish to rename the project in the original branch spec to simplify this process.

Subversion

Subversion uses the same copy and delete method for relocating files and directories as Perforce, but has no provision for recording those mappings. Developers must use shell scripts or other means to record the mappings to maintain continuity between sustaining development and ongoing development. It is a pity, really, since Subversion did go through the trouble of keeping directories as versioned objects, but ended up using the location of an object as the primary key for referencing. In other words, the versioned directories act as a fancy substitute for Perforce's "..." wildcard, by allowing operations to be performed recursively on directories.

Another issue is Subversion's lack of support for transitive merges. This may be fixed by now, but the absence of that capability makes it hard to change your mind about the final mapping. For example, suppose you initially wished to rename a file one way, then made some changes, then renamed it again, and then wanted to merge from sustaining development, you would have been required to retrace all the steps in your renamings.

Remote Users

Considered here is the easy of use for remote and offline workers.

ClearCase

In its original form, ClearCase requires network connectivity. Since the introduction of snapshot views, the situation for offline and remote workers has become manageable. The following procedure seems to work fairly nicely:

Set up a "docking view server" with automount capability.
Set up laptop computers as NFS servers which export to the docking view server.
Add a login script to the docking view server which identifies the laptop from which the login originated and mount the exported NFS partition, which just happens to contain the root dir of the snapshot view.
Resolve hijacked files. The extension pack has this built-in.

Nevertheless, for heavy weight merging and reorganizing, dynamic views are much better suited.

Perforce

Offline work is possible in a way similar to ClearCase's snapshot views. Simply edit the files, then, once back and connected to the server, use p4 diff -se to locate the files you changed and check them out and resync. Heavy duty branching and merging needs to be done online, but code development and the addition of new files can be done offline.

Subversion

Not enough information at this point, but it would seem that one can do at least as well as Perforce.

Distributed Development

ClearCase

ClearCase's MultiSite product provides a very neat replication solution. Nevertheless, your branching and merging procedures need to be up to the task. The extension pack can help, and procedures exist.

Perforce

Perforce provides no good replication solution. Perforce does come with a proxy server which can help resolve most performance issues when separated from the server by a slow connection. It may be possible to manufacturee a replication solution by combining a local server with a proxy to the remote server and using clients of both sharing the same client root, and then scripting a process which translates the output of a p4 sync of the remote client to edits, adds and deletes on the local client.