Migrating ClearCase Branches to TFS

After working with several customers on their migrations from ClearCase to TFS, it was evident that one of the big challenges of migrating between such vastly different version control systems was determining an appropriate branching structure.  This was the result of both the varied branching models of TFS and ClearCase, as well as the best practices encouraged and best adapted to each system.  Below are some high level explanations of the branching models of each system, how the aforementioned migration tool migrates branches, and recommendations on how to choose the correct set of branches to migrate from ClearCase to TFS.

ClearCase Branching

ClearCase users are familiar with just-in-time branching in version space - that is, new versions of individual files and folders are created when the file is edited on a branch.  This means that only when a particular file is checked-out on a branch is it even created on the branch.  Until then it lives on the parent branch that is determined by the config spec.  The config spec also defines how the right versions of files are selected from branches, and which versions should be defaulted to if a file doesn't exist on a branch.

TFS Branching

In TFS, branches are created early, and branch in path space.  This means that as soon as a branch operation is checked-in, all of the items under the branched path now exist on that branch.  Files from the branch are edited and checked-in to the branch, and files that are never edited on a branch also reside on the branch.  Since the contents of the branch are determined at creation time, there is no need for users to have config specs that pull together the correct items to form a usable/buildable branch.

(For details on TFS branches and branching strategies, visit the TFS Branching Guidance page on CodePlex: http://www.codeplex.com/BranchingGuidance)

Migrating Branches from ClearCase to TFS

The disparity between ClearCase and TFS branching leads to some challenges when migrating branches.  Clearly, config specs are integral to determining the correct files to select for a branch in ClearCase.  For this reason, the TFS to ClearCase migration tool requires a config spec for each branch to be migrated.  Using this config spec, the tool is able to create TFS style branches out of the ClearCase branches.  What that means, is that files that never technically existed on a ClearCase branch will now exist on the TFS branch. 

Although this strategy is not truly preserving the data as it existed in ClearCase, it is a necessary transformation to ensure the usefulness of branches in TFS.  For example, without all of the correct files on the branch in TFS, the files will no longer build.  Merging files back into parent branches is also impossible without all of the correct files in TFS, essentially defeating the reason to branch in the first place.  For these reasons, the tool takes the liberty of adding the files to the branch, as specified in the config spec.

For more details on how the TFS to ClearCase migration tool migrates branches, see  the documentation that is installed with the tool.

Which branches should I migrate?

In some cases, ClearCase VOBs can contain a very large number of branches.  This is often because many users will create many short lived branches used to fix bugs or add new features.  In TFS, the branching guidance is to keep a smaller number of branches, typically, Main, Dev, Production, and the feature branches off of Main (see the TFS Branching Guidance for details).

In order to keep the time to migrate files at a reasonable level, and to avoid a complex branching structure in TFS, the guidance for migrating branches is to migrate those ClearCase branches that are synonymous to Main, Dev, and Production.  It may also be desirable to migrate some specific feature, release, or bugfix branches, but the rule of thumb should be to minimize the number of branches migrated to TFS.