The documents Migration Guidance, ClearCase Migration Guidance, Perforce Migration Guidance and Subversion Migration Guidance on http://tfsintegration.codeplex.com all highlight that there are different migration strategies, which should be carefully reviewed before making a choice of the migration or synchronisation strategy.
This post summarises a few important topics from a number of the guidance documents, to emphasise two recommendations:
- Recommendation 1: Consider in-place upgrade over migration … it is a strategy that is effective and does not result in the loss of data.
- Recommendation 2: Consider migration over synchronization where you can … it is simpler and more cost effective.
Let’s have a look at both the migration and synchronization strategies, as they relate to version control.
A big-bang migration is not always feasible, but is generally best for small teams with manageable process-related tooling needs. The short-term impact can be considerable, however, the ongoing maintenance effort and cost is close to zero. Also it is difficult, if not sheer impossible, to calculate the computation required to migrate data that has been accumulated over years, making it important to perform representative migrations during the pilot phase as highlighted in TFS Integration Platform – Planning a migration … starting with a solid foundation.
When you are looking at the data iceberg, you have to decide whether it is really necessary to migrate all the history (worst case), selected history or the latest state (recommended). The product documentation and guidance includes the following scenarios:
- Snapshot … moves the latest state, based on the realisation that complete history is usually not required and seldom missed.
- Selected History … uses the snapshot concept, but moving the latest and a selected slice of the history.
- Archive … moves the entire iceberg of history. Reconsider any decision to opt for this strategy.
If ……………. and only if …………….. migrations cannot be performed within a manageable down-time maintenance window or if a business requirement necessitates the source and target environments to co-exist, should you consider synchronization, else goto recommendation 1.
As with migration, less is better, simpler and less expensive. Maintenance and monitoring becomes an integral and costly requirement of a synchronization environment, which needs careful planning, implementation and support.
The synchronization strategies for version control data define the scope of bi-directional migrations. The current migration refers to three strategies as shown:
- Simple … synchronise a single integration path, for example the main branch, from source to the other.
- Multiple … synchronise a set of independent branches from one source to the other.
- Full … synchronises all branches … again reconsider any decision to opt for this strategy.
IBM Rational ClearCase Terminology
Some interesting and commonly used ClearCase terminology included in the guidance documentation that we should highlight:
||A branch represents a separate line of development of elements. In ClearCase the branch is visualized using a top-down approach as shown on the right.
||The configuration specification, commonly referred to as config spec, defines a set of rules which versions of VOB elements a view is based on.
element * CHECKEDOUT
element * .../main/ tfs_integration_branch /LATEST
element * /main/LATEST –mkbranch
A view makes a VOB appear to be a standard directory tree, by selecting one version of each version-controlled object, defined by a Config Spec (configuration specification) that contains an ordered set of rules for selecting versions of elements.
The view defines a workspace for users, using a configuration specification to define element version mapping as shown below on the right.
The version object base (VOB) is a repository used to store file and directory elements, objects and metadata.
Some things (gremlins) to ponder over before doing a migration from CC to TFS
- A migration from ClearCase to Team Foundation Server (TFS) requires configuration specifications for ClearCase for each branch to be migrated.
- ClearCase VOBs can potentially contain a very large number of branches, which must be consolidated/simplified as part of any strategy.
- ClearCase uses a just-in-time file-level branching, creating new files and folders as the files are changed, while the Team Foundation Server (TFS) uses create-early directory-level branching, creating files on a branch as they are checked-in. This creates a potential disparity between a ClearCase and a TFS environment, that is not a problem if known.
- We have had troubles with dynamic views on Windows Server 2008.
- Windows 2008 R2 and Windows 7 are not supported for ClearQuest/ClearCase.
- SQL Server 2008 cannot be used for ClearCase 220.127.116.11
- … there are probably more gremlins and I will update this list as we find them
That’s it for today. Next time we will do a similar journey looking at a potential migration from Subversion to TFS. See you then …