VSTS Rangers Projects – TFS Migration: Questions and Answers 2

Last week we posted a batch of questions and answers in the post VSTS Rangers Projects – TFS Migration: Questions and Answers. Here are two more questions we have received and the appropriate answers:

For conflict resolution does the resolution order matter?

The resolution order is scope-based. Each conflict has a scope hint and each resolution rule has a scope, whereby the same scope interpreter is used to interpret them to ensure they are in the same syntax. The resolution order is always tightest scope first. Example, if the scope hint of a conflict is /root/folder1/folder2, and there are two rules with scopes of /root and /root/folder1 respectively, the latter will be applied.

The default conflict resolution policy for WIT is to continue migrating/writing data to the target system even after conflicts are detected.  This generally makes sense because WI’s are relatively self contained.  The complex relationships and natural historical sensitivity of VC make stopping the actual migration of data on the first detected conflict the better policy.  For VC a complete analysis is done so that all of the detectable conflicts are reported up front.  There are classes of VC conflicts called content conflicts for which both systems have to be brought to the point of the conflict so that it actually makes sense to invite the user in to help resolve the issue. 

Think of the edit/edit conflict where two people are fighting over the same file on synchronized servers.  The migration framework will know ahead of time (analysis phase) that there is a conflict ahead, but is working under conflict type-specific policy that says that for this content conflict, all changes have to be played up to the point of the edit/edit conflict before it makes sense to generate a shelveset with the pending conflicting change and ask a user to fix the problem. 

There may be other conflict types in VC or in WIT where migration would not be started when a conflict exists.

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?

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” .

I am sure that “we’ll be back” with more :)