TFS Integration Platform – Why am I getting a “Conflict Type:VC path not mapped conflict type” Question & Answer 24

A support thread recently caught my attention, whereby the eye of the problem was focused on the following error encountered during a migration … note that GUIDs and names are fictitious:

[2010-03-23 11:29:41] MigrationConsole.exe Information: 0 : VersionControl: Analyzing 1/1: 1 items in root: $/DEV-2
[2010-03-23 11:29:41] MigrationConsole.exe Information: 0 : VersionControl: Unresolved conflict: 
[2010-03-23 11:29:41]   Session: 1234567e-8776-4458-a0bc-1a9638123456
[2010-03-23 11:29:41]   Source: 12345675-46f5-40a4-9a38-d95cf9123456
[2010-03-23 11:29:41]   Message: Cannot find applicable resolution rule.
[2010-03-23 11:29:41]   Conflict Type:VC path not mapped conflict type
[2010-03-23 11:29:41]   Conflict Details: '$/MAIN’ to be migrated is not mapped

With collaboration with the TFS Integration Platform development team and by re-using Bill’s explanation in one of his email response we have been able to consolidate this post. Thanks guys for all the input and reviews!

So why are we seeing the VC path not mapped conflict type?

Let us consider the following branching scenario … we branch from main to dev-1 and dev-2:
… diagram copied and re-used from TFS 2010 Branching Guidance.

We the configure the TFS Integration Platform to use a filter pair $/DEV-2 (1) , cross our fingers and start the migration. The result, as you may all guess, is the conflict as mentioned above … but why?

What we are seeing is a common “path not mapped” conflict (2) , which happens when we move a tree, or rather part thereof, with a with branch/merge relationship without considering all of the parent items.

In the above scenario we naturally picked DEV-2, assuming that the tooling will do what we want. However, the tooling correctly questions whether your assumption is actually intentional and consequently raises the conflict. The tooling warns you that it will not be possible to fix the problem later, if we leave the merge/branch history from MAIN to DEV-2 behind.

Resolution – Option 1 … if we do not want to leave the history behind

• Option 1.1
  • Launch the new TfsMigrationShell, which you will find in the TFS to TFS Connector Tool directory, and select the Conflicts tab. As part of the listed conflict(s) you will see the path not mapped conflict, with a range of possible resolutions.
  • Chose the 'Add' for 'Branch', by skipping for 'Merge' and by changing to 'Add' for 'Rename' resolution.
  • Take note that the conflict resolution actions have a scope, which by default are narrowly focused on the specific path or item that caused the conflict. 
    • For version control you can tell the system that you want the resolution rule to apply not only to this specific conflict, but any others like it under a given server path. 
    • If you are certain that your filter pairs identify exactly what you want moved to the target system and you don’t care about any of the other branch/merge relationships you are leaving behind, you can change the scope of the resolution rule to $/ so that it applies to everything under that path – which is everything.
• Option 1.2
  • Update the filter strings such that ‘branch from‘ path exists, to instruct the VC Adapter to preserve branch/merge relationships.
  • Add the following additional filter pair to the configuration file:
    <FilterPair Neglect="false">
                <FilterItem MigrationSourceUniqueId="guid1" FilterString="$/Main" />
                <FilterItem MigrationSourceUniqueId="guid2" FilterString="$/Main" />
    </FilterPair>

Resolution – Option 2 … if we want to leave the history behind

• Using the snapshot starting point feature, as covered in I have just moved my VC content, now I want to sync from a specific snapshot … now what? we can define a starting point that starts after the branching snapshot and “intentionally” ignores all history. In other words, we notify the tooling that the our assumption to ignore history is intentional and that we are fully aware of the consequences.
  
• Using this option all the branch/merge operations before the snapshot point will be migrated as Add/skip and ensures that you will not encounter any PathNotMapped conflict.
• Note that to migrate a merge change after the snapshot, the tooling will still try to migrate the operations as a merge and if we are missing the mapping to the parent a PathNotMapped conflict will once again knock on our screen.

Hyung, mentioned a good possible question, namely “what would happen for the FIs from Main to Dev-2 after snapshot start point?” Since we left history behind, the VC adapter would raise ‘History Not Found’ conflict which we could again resolve. Watch the space for a blog on this topic :)