TFS Integration Tools – VC Conflict “A namespace conflict has been detected” … what now?
To reproduce this conflict we create a directory ConflictData containing two text files, as shown below, in both the team project from which we will migrate and in the team project to which we will migrate both the VC and WIT data using the TFS Integration Tools. The directory and the two files are checked in separately, so that we will generate the conflict for each file, which we will handle separately for clarity.
NOTE: This post was created during a past-midnight debugging session and will therefore probably be subjected to ongoing panel beating and clean-up for a while.
If you are wondering hoe to get started with TFS Integration Tools, we suggest you first review the following:
TFS Integration Tools (Platform), section “Starting Nuggets":
- Where does one start? … part 1 (documentation)
- Where does one start? … part 1b (pre-requisites)
- Where does one start? … part 2 (try a simple migration)
- Where does one start? … part 3 (dust has settled …. did it work?)
- Where does one start? … part 4 (Mapping users the easy way)
Why are we getting a conflict in the first place? Well, we have the same file in both the source and the target and the TFS Integration Tools is unable to decide which is the correct version.
As the names imply, we have a hypothetical scenario in which all changes made to the file ConflictFile_SourceWins.txt on the source system should be applied, whereas all changes made to ConflictFile.TargetWins.txt on the target system should be applied by the migration.
We are therefore going to throw away changes made to the ConflictFile_SourceWins.txt on the target system and ConflictFile.TargetWins.txt on the source system as shown in the following diagram:
After configuring the migration session, we click Start.
As expected, we encounter two conflicts.
When we look at the details, we note that the two files (as expected) are the culprits.
We look at the details of one of the changesets, in this case #57218, which contains the add operation for the ConflictFile_SourceWins.txt file.
When we compare the ConflictFile_SourceWins.txt on both the source and target system. It is apparent that the file is different.
The same applies for the file ConflictFile_TargetWins.txt file.
As shown below, there is a “click here” hyperlink, which takes us to the relevant version control conflict definition and suggested resolution:
After reading the description and resolution suggestion, we checkout the ConflictFile_SourceWins.txt file on the target system and manually apply the changes made on the source system. We then checkin the changes as changeset #1793, description “Manual Merge of Source Changes”. We would probably merge the changes from both the source and target in a real-world scenario, but we have the hypothetical scenario that changes from the source must win for this file. To merge changes made in both the source and target the overall process would be same, but instead of just moving source changes into target, we would have to invest some additional time to analyse and merge the deltas.
What is worth highlighting is that the following conflict dialog is probably VERY confusing, because the source changeset version refers to the local (to) team project and the target changeset to the other (from) team project. As highlighted by (1), the source and target systems are swapped from the way we configured the source and target systems in our session configuration. We have raised this anomaly (depending on which view of the system you have)with the product team and hope that we can rename the column headers and the field descriptors to something like “From” and “To” changeset information.
(2) To resolve the conflict for the ConflictFile_SourceWins.txt file, we define the changeset #57218 to be replaced with changeset #1793, as shown. This tells the TFS Integration Tools that it should accept the manual merge changeset as the conflict resolution.
We do the same for the ConflictFile_TargetWins.txt file. In this case we do not have to merge any changes, just instruct the tools to take changeset #1777 as the one to apply.
When we re-start the migration, we complete with no further conflicts. The changes made in ConflictFile_SourceWins.txt on the source are now reflected on the target system, while changes made to ConflictFile_TargetWins.txt on the target are maintained.
Also refer to Where does one start? … part 3 (dust has settled …. did it work?) which discusses the same conflict and resolution thereof.
Comments
- Anonymous
November 04, 2016
The comment has been removed - Anonymous
March 22, 2017
Hello, I am trying to migrate an agile project to a scrum project and I get this conflict, but when I put the correct chagenset, my tfs integration does not find the chagenset, you know why?A greeting