In the TFS Migration Tools – Getting Started hands-on-lab (HOL) document we introduced the basics, stepping around all possible conflicts with care. For this that know the Migration Toolkit (and its predecessor), the conflict resolution command line tool and the associated complexity are feared. The complexity makes the use of the product immensely frustrating and error prone … which is why we avoided conflicts for the 45-min HOL.
But our fathers were men, and their fathers were men … so we decided to rename the existing HOL as the “Basic Scenario” and are in the process of adding an “Advanced Scenario”. The new scenario undoes all our step-around-the-conflict setup and walks towards the Work Item Tracking (WIT) and version Control (VC) conflicts, tacking each one and using the opportunity to introduce the new Windows Presentation Framework (WPF) based user interface.
Undoing some of the safety nets
We assume that you have either completed the TFS Migration Tools Getting Started Hands-On Lab (HOL), or that you have perused the posts VSTS Rangers Project - TFS Migration Tools: Configuration Demystified, VSTS Rangers Projects – TFS Migration Tools: Getting Started Questions and Rangers Projects – TFS Migration Tools: Where has the link relationship vanished and why? as a backgrounder.
In essence we created a new project TP-C, copied our SampleConfig.xml file, changed TP-B to TP-C, changed the WorkflowType to OneDirectionalSynchronizationWithoutContextSync for a one way synchronization with no context and commented out the EnableBypassRuleDataSubmission, which in essence disables the feature.
The EnableBypassRuleDataSubmission was enabled in the previous scenario where we tried to hide from conflicts. Is a property set in the WIT update document; if set to true, all the WITD rule evaluations, such as valid value list, state transition, are disabled for the submitted data.
Warning: Specifying false for the attribute SettingValue makes no difference as the current schema ignores that attribute. Either comment out the line or delete it … else you will be as puzzled as I was for a very long time.
When we now run the synchronization, we are stopped by a WIT conflict: “TFS WIT general conflict type”, which has raised its heads as a direct result of us not using the “EnableBypassRuleDataSubmission” rule anymore.
Using a manual rule to restore peace and order
We chose to create a manual rule in the session configuration file. We define an exclusion rule when moving WITs of type Bug and Task from the left source to the right target, resolving the WIT conflict on the State Change Date field.
SampleConfig_CR-Final.xml with the relevant changes applied
We now re-run the synchronization by running MigrationConsole.exe SampleConfig_CR-Final.xml … huh … only to shake hands with the same conflict.
Confusion and panic is about to set in … until we realize that we changed the configuration file, but not the configuration in the migration database. We have to change the configuration unique ID to force a re-load of the complete configuration file and the session unique ID to force a re-load of the updated session configuration.
Update both GUIDs, re-run the migration console and voila, the WIT data starts flowing again.
As you can see the manual rule involves manually editing a XML file (not my favourite hobby) and manually updating the configuration file unique ID and the session unique ID, to ensure that the changes and moved to the migration database. A very tedious and humanoid error prone process.
Now that we have briefly explored the manual way of working with conflicts and setting up rules, we will explore the new conflict resolution tool. See you back shortly for a more user friendly and less painful conflict management experience.