We have a TFS 2010 server with 1 main TFS Project and ~10 very small TFS projects, all in the same collection. Per these recommendations we want to migrate the 10 small projects into our main Project. We explored accomplishing this with TFS Integration (in a sandbox environment). The Work Items migrated fine. (Well, in our first test project there was only 1 Work Item.) Then the Version Control migrated fine. However, the 5 Changesets were not linked to the migrated Work Item. Any ideas why this might happen? I didn't see anything obvious in the logs.
Thanks for your post!
Please be aware of the Limitations that exist for this platform, as outlined on the following:
What IS NOT migrated by the Toolkit
- Check-in notes
- Pending Changes
- File encodings
- Test Cases
- Check-in policies
- Team Portal / SharePoint
- Process Templates
- Work item queries
- Warehouse data
For more information, please refer to http://visualstudiogallery.msdn.microsoft.com/eb77e739-c98c-4e36-9ead-fa115b27fefe
Hope it helps!
Cathy Kong [MSFT]
MSDN Community Support | Feedback to us
Hi, apologies if I'm missing something, but this isn't helping me. The small test project consisted of 1 work item, which had 5 linked changesets. The work item and changesets migrated, but the links did not. The links are supposed to migrate - at least that's my understanding. I tried a different test project that was a little larger, and most (if not all) of the linked changesets did migrate. One potentially interesting aspect with the problem is that all 5 changesets involved at least 1 file rename or file delete.
Yes, I chose the the standard Source Control & Work Items (one-way) option to migrate everything at once.
Regarding source control:
All of the files in the changesets resided in TfsProjectA\...
Well ... I have an "unofficial answer" :
I just reproduced this behavior with a complex migration. (WIT mapping fields, complex branch schema...)
And that's right :
At the end of the session, WIT and changesets were not associated.
I had to launch it again to "finish" the association.
I don't understand why it does not happen on a "simple" migration with basic source code & WIT.
So I have an update... after applying this workaround to our test environment and seeing positive results, I ran the migration in our production environment. Once again the linked changesets did not migrate. Unfortunately this time clicking Start again did not correct the issue. (I even tried it about 5 times but I've been told that's the definition of insanity. :-) ) Again there's nothing that stands out to me in the logs. One Work Item had an External Link Count of 23 at the source, and this was the matching log entry in TFS Integration:
[9/21/2012 5:07:56 PM] TfsMigrationShell.exe Information: 0 : WorkItemTracking: Generating linking delta for non-Work Item links for Work Item: 16594
[9/21/2012 5:07:56 PM] TfsMigrationShell.exe Information: 0 : WorkItemTracking: Detected 23 non-Work Item links for Work Item '16594'
I don't see anything after that to indicate success or failure.
I believe the problem is related to branches.
In the past the following happened:
Added stuff to $\TfsProjectX
Moved from $\TfsProjectX to $\TfsProjectA\A.00.00
Renamed $\TfsProjectA\A.00.00 to $\TfsProjectA\Main
Branched Main to $TfsProjectA\A.00
Did a bunch of development
Ran TFS Integration to migrate the data to $TfsProjectB\FolderA\[Main, A.00, etc.]
If I create a test file at $TfsProjectA, the file, the workitem, the changeset, and the link between the work item and changeset all come across successfully.
If I create a test file at $TfsProjectA\A.00 or $TfsProjectA\Main, the link does not migrate.
During the migration I received conflicts because TFSIntegration didn't know about $\TfsProjectX and $\TfsProjectA\A.00.00. In these cases I always resolved by Add New. Could that have created this bizarre side effect?
Does anyone know how I can fix the issue? Thanks in advance.
On which path did you run the migration ?
If you ran the migration on a branch, I guess you face this issue :
In my case, I got the best results when I migrated all the source code hierarchy and permanently deleted the old branches.
"Old branches" = deleted or renamed branches.
- Proposed as answer by akam74 Sunday, September 23, 2012 6:38 AM
Thanks for your help Akam74! The tool migrated from $\TfsProjectA. to $\TfsProjectB\FolderA.
It's unfortunate that the TfsIntegration tool lost the links to the changesets. It certainly seems related to the branch stuff, even though 95% of the changesets occurred after the branches were converted to Add New. There's really no reason for it as far as I can tell.
Because I didn't want to permenantly delete the branches and renames (in the event this exercise became a failure, I want something to go back to), and because I didn't want to re-run the migration and have more duplicate code and work items, I opted to write a tool to re-link them myself.
To match source work items with destination work items, I matched on fields such as Title, etc. To match the source changesets with the destination changesets, I leverage the fact that the source changeset is burned into the destination changeset's comment by TfsIntegration. [string delimiter = @" (VC)' Id: ";]
Sample tool logging:
29227 : 56631 ,
29235 : 56663 ,
29587 : 57505 ,
29652 : 57639 ,
31173 : 62236 , 62235 , 62231 , 62095 ,
31507 : 62234 , 62233 ,
31509 : 72459 ,
31510 : 62232 , 62230 ,
31575 : 62603 , 62602 , 62420 ,