VSTS Rangers Projects – TFS Migration: Questions and Answers

  • Article

As mentioned in the post VSTS Rangers Projects – TFS Migration: A state of the nation status update, we are busy reviewing some of the new and also existing re-factored artefacts. The following questions and answers are some of the questions that we have received and the associated answers. The references for the questions are listed below:

  • AIT. (2009). TFS Migration and Synchronization "Toolkit How To Guide". AIT Applied Information Technologies AG.
  • Olausson, M. (2009). Project Correspondence. VSTS Rangers.
  • VSTS-Rangers. (2009). TFS2TFS project Copy VSTS Rangers Team.

Clipart Illustration of a White Person Holding Red Text Reading Under Construction Some of the top questions

What adapters are planned by the TFS Migration Tools team? (Olausson, 2009)

All of the current Microsoft solutions, like CC to TFS and QC to TFS are good candidates for adapters that may be ported to the new platform. The current goal, however, is to enable partners to build solutions and for the TFS Migration and Synchronization Toolkit team not to develop any further adapters. Currently the TFS2TFS and WSS2TFS adapters are tested samples of custom adapters, based on the new toolkit.

Will a User Interface be released or are we stuck with the console application? (Olausson, 2009)

A graphical user interface is planned and will be released as part of future TFS Migration and Synchronization Toolkit releases.

Will there be a windows service, in place of the console application, which will allow continuous synchronization? (AIT, 2009)

In the new toolkit, there will be a windows service in place of the console application, which will allow users to implement continuous synchronization.

Can I perform concurrent, more than one, synchronization pipeline? (AIT, 2009)

The new Windows Service host will be able to handle this requirement.  The Windows Service will be looking to the DB for active sessions, will restart/resume ones that need that sort of treatment and will pick up new ones concurrently.

Will v2 allow me to trigger synchronization other than by a timeout event as is the case in v1? (AIT, 2009)

The toolkit is currently timeout based, but there are plans to expose a refresh trigger on a WCF endpoint exposed by the Windows Service.  Using the refresh trigger, TFS check-in events could be used as a trigger condition.

Why are all classes, i.e. the classes used for work item tracking synchronization, in one namespace? (AIT, 2009)

The V0.1 toolkit is TFS-biased and the adapters, especially the WIT Adapter, are tightly coupled with the toolkit. In the new toolkit there is clear separation of the toolkit and the adapters, i.e. the toolkit won’t have any reference to the TFS assemblies and adapter classes are intentionally not packaged in the Toolkit namespace.

Why is the WIT Adapter called “TfsWitAdapter” and the VC Adapter “TfsAdapter”, and not TfsVCAdapter? (VSTS-Rangers, 2009)

The new version of the toolkit features a re-factored code base, which features a TfsWitAdapter and TfsVcAdapter, for example.

What is your guidance on how to handle conflicts when an ongoing synchronization is taking place - is the synchronization paused until the conflict is resolved? (VSTS-Rangers, 2009)

  • For VC, the default policy is to stop on any conflict and that is what we do. VC would typically only have one conflict to resolve in a real run.Clipart Illustration of Two Orange People On Blue Puzzle Pieces, 
  • For WIT, the default policy is to continue.

If the TFS2TFS tool/runtime and process fail during an ongoing synchronization does the tool have any idea of the failure the next time it launches that session? (VSTS-Rangers, 2009)

All unresolved conflicts are persisted to the Migration DB.  If power is shut off to one of the servers in a mirroring relationship, for instance, it would currently translate into one of the built-in conflict types - a general toolkit conflict.  This is used to wrap exceptions and other runtime events that the migration framework does not understand as a conflict, whereby the only resolution action at the moment is "manual resolution".  That basically means ... “I'm the user and I've fixed the problem - try again”. 

The idea with conflict types is that adapter writers might selectively pick classes of issues out of that general pool and name them to associate more specific and relevant resolution actions.  That network communication failure, for instance, might be raised as a GeneralNetworkCommunicationFailure conflict in the future and the user might have a resolution rule in scope for that conflict type that says something like ... “any time you see this, I want you to try up to N times over M minutes before giving up and calling this an unresolved conflict” .

The End … for today

Please send us additional questions which we can answer and include in our TFS Migration guidance.

Until next time, cheers.