TFS Migration Tools: Conflict resolution … a peak at the (less painful) future: Part 4

In this post we will focus on version control (VC) conflict resolution, removing one more work around from our hands-on-lab (HOL) environment and looking at another common conflict.

Let the games begin. Remember the following notice in the HOL manual?

NOTE: We are using $/TP-B/Fix as the target version control root to avoid a “VC content conflict type” conflict being reported by the TFS VC Adapters, as we are not including the configuration and administration of conflict rules in this walk through as we are only using command line tools, not the new GUI user interface, and as the command line tool can be challenging. This is a known issue, which will be resolved in the final release.

In the revised configuration file we have removed the “Fix” and defined the FilterItems as follows:

    1: ... extract
    2:         <Session SessionUniqueId="7092283E-8776-4458-A0BC-1A96385C635F"
    3:                        FriendlyName="CR Version Control session"
    4:                        LeftMigrationSourceUniqueId="13828D85-46F5-40A4-9A38-D95CF96B01DB"
    5:                        RightMigrationSourceUniqueId="9848394A-112D-4B8B-9866-0E309BB372CB"
    6:                        SessionType="VersionControl">
    7:           <CustomSettings>
    8:           </CustomSettings>
    9:           
   10:           <Filters>
   11:             <FilterPair>
   12:               <FilterItem MigrationSourceUniqueId="13828D85-46F5-40A4-9A38-D95CF96B01DB" FilterString="$/TP-A" />
   13:               <FilterItem MigrationSourceUniqueId="9848394A-112D-4B8B-9866-0E309BB372CB" FilterString="$/TP-C" />
   14:             </FilterPair>  
   15:           </Filters>
   16:         </Session>
   17: ... extract
   18: </Configuration>

So, instead of moving from $/TP-A to $TP-C/Fix, we move to $/TP-C … what is the more natural scenario. The state of TP-A is a team project where work has been done and TP-C has just been created … fresh out of the box with an empty source control repositiry.

First we attempt a synchronization …

As always we run the program MigrationConsole.exe, passing our configuration file with the change (remove Fix) as mentioned earlier. Simple and nothing that scares us these days.

Then we stare at the conflict …

“Alarm”, helmets on … we have conflicts of type VC content conflict type, a common conflict we have seen when synchronizing an existing team project to a new team project environment.

Fire up the new Conflict Resolution Tool and resolve …

As in previous posts, we locate the program ConflictManagementTool in the TFS Migration Tools folder and run the application. We will be presented with the same conflicts in a slightly more humane manner:

Starting at the top, we select each conflict and chose the resolution action ‘carefully’. In this case we opt for “Resolve VC content Conflict by always taking local changes” … in other words we win, our changes are the right ones and we move our changes to the target.

Once you have resolved the first two, you will notice that all four conflicts are shown as resolved by the green light on the left. We can then run the program MigrationConsole.exe again and will notice that we have good weather conditions again … the conflicts have been resolved.

Lastly, what if a file is edited on both the source and the target environment?

As shown, the (1) user in TP-A makes a change to the file $/TP-A/Demo/Example.cs. At the same time (2) another user makes a change to the file $/TP-C/Demo/Example.cs.  When we finally run the sync (3) from TP-A to TP-C, we will detect a VC content conflict and stop the VC synchronization bus.

When we are dealing with a VC content conflict, we have three options at this stage.

1. Take local (source) changes
2. Take other side’s (target) changes
3. Allow user to merge changes manually

For the last scenario (3), we would manually check in fix-up changesets to both the source and target system, record the checkin changeset details and then create a resolution rule and provide the checkin changeset details in the resolution rule.

… what’s next? Good question, we have not made up our minds yet :|