TFS Integration Tools – Where does one start? … part 3 (dust has settled …. did it work?)
We continue from TFS Integration Tools – Where does one start? … part 1 (documentation) and TFS Integration Tools – Where does one start? … part 2 (try a simple migration). In this post we look what happened after “gently” selecting START.
Remember the following …
- We configured the session using no customizations, such as field or value mapping … out of the box.
- We have not worried about permissions.
… let’s see what happened after a few minutes of analysis…
Resolving the conflicts
WIT Conflict
The first “stop-the-bus” conflict was raised by the WIT session and had we read the configuration guide we would have noticed that by default the EnableBypassRuleDataSubmission rule is enabled, which requires the credential of the migration user to be a member of the Team Foundation Service Accounts group.
Using the TFSSecurity tool we can add the credentials to the Team Foundation Service Accounts group, by running the following command as shown below:
tfssecurity /g+ srv: @SERVER@\Administrator /server:@SERVER@ , whereby we are using the Administrator credentials.
After this fix, the 1000+ entries wandered across the copper cable … or is that WiFi copper-less network?
VC Conflict
The VC session was the next to pull the migration hand-brake with the following conflict:
The conflict was thrown in our case, as the three template files exist in both the source project and the new target project, as created during the team project creation. Which is the right version? Well, the tool cannot make any assumptions and therefore stops the bus … or rather migration pipeline.
As shown above, there is a “click here” hyperlink, which takes us to the relevant version control conflict definition and suggested resolution:
In essence we have to look at both the team project we are migrating from to find the relevant changesets …
![]()
… and the team project we are migrating to:
What is worth highlighting is that this specific 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. 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.
Take a look at the migration log
Scrolling through the 1.3MB log file would probably be very, very boring. for this blog post, but definitely worth a visit. It reports, in great details, the standard pipeline processing as documented in the architecture documentation:
- Generate Context Information Tables
- Generate Deltas on the originating point
- Generate Link Deltas on the originating point
- Generate Deltas on destination point
- Generate Link Deltas on destination point
- Generate Migration Instructions
- Post-Process Delta Changes
- Process Delta Changes
- Analyze Link Delta
- Process Link Changes
and conflicts if any:
[5/15/2011 10:51:32 AM] TfsMigrationShell.exe Information: 0 : VersionControl: Unresolved conflict:
[5/15/2011 10:51:32 AM] Session: e8853f21-3ab0-425c-817b-917b3d93ca60
[5/15/2011 10:51:32 AM] Source: 172f78a5-b891-4f7b-8f0e-f2cf4b4610cd
[5/15/2011 10:51:32 AM] Message: Cannot find applicable resolution rule.
[5/15/2011 10:51:32 AM] Conflict Type: VC namespace conflict type
[5/15/2011 10:51:32 AM] Conflict Type Reference Name: c1d23312-b0b1-456c-b6e4-af22c3531480
[5/15/2011 10:51:32 AM] Conflict Details: $/TiP_POC_Test_2/BuildProcessTemplates/DefaultTemplate.xaml
[5/15/2011 10:51:32 AM] TfsMigrationShell.exe Information: 0 : VersionControl: Stopping current trip for session: e8853f21-3ab0-425c-817b-917b3d93ca60
Take a look at target team project
The TFS Integration UI gives us a “thumbs up”, having moved 12 changesets and 1320 WIT items.
At the bottom of the UI we will also see the graphical chart. If we hover over one of the red bars, we will recognise the event where the VC conflict as reported above was reported:
Seeing is believing and therefore we should review the target team project and verify that everything has been migrated … which was the case.
Looking at one of the VC changesets, we notice that additional information was added to the description, reporting which (1) tool and who (2) moved the changeset:
What may not be apparent at a first glance, but is clearly documented as a limitation in the branching guidance, is the fact that the creation date is that date and time when the changeset was checked in by the migration tool, not the original check-in date you would find on the source (from) system. The migration guidance document defined this limitation as follows: “Timestamps on work item revisions and changesets will be updated to the time of migration. Any work item fields that store date time information will have their values correctly migrated, but the time of the revision will not be migrated. The most significant impact this has on a system is in reports that rely on a time dimension (i.e. Bug Trends, Code Churn). Because the migration typically occurs over a much shorter time span than the original operations, the time axis in such reports will effectively be compressed. ”
Looking at one of the WIT items, we also notice additional information on who moved the item (2) and the same date/time (3) limitation as outlined above.
The other limitation which you will noticed when doing a VC by VC changeset or WIT by WIT comparison is the following, as documented in the migration guidance document: “Work Item IDs and Changeset numbers are not preserved during migration and new IDs are assigned sequentially as items are migrated. This implies that any references to these IDs will be invalid after migration; however, the links between work items and changesets will be migrated correctly, despite the ID changes. ”
Lastly it is important to remind ourselves, as outlined in the previous blog post, that we are moving from one domain to another, not using value mapping and therefore it comes as no surprise that the “Assigned To” defines the credentials from the source (from) team project, which may not and in our case are not valid credentials on the target (to) team project.
Next
In the next blog post we will demonstrate a simple field value mapping to change the “assigned to” field value to users that are known and valid on the target system. Also see the following blog posts for related information:
See you next time.