3
votes

A 3rd party has developed some applications for us and has been using MS Team Foundation Server 2008 for their source control. My company has recently setup our TFS 2008 environment and we're trying to migrate the source code from the 3rd party developer TFS to our TFS machine. You first thought was to try the backup and restore method of migration but the only SQL Server we have available is a Standard Edition license and the 3rd party developer's SQL Server they are using for TFS is Enterprise Edition. Which means the backup and restore method will not work. So I've been trying to get the TFS to TFS Migration Tool (found on codeplex) migrate the source code. Sadly I've been having issues...

The 3rd party developer network is in its own sub-network within our company's network. And they have their own domain separate from us. So their TFS machine is on their domain, our TFS machine is in another domain, and my PC (which has VS, Team Explorer, TFS Power tools...) is connected to both networks and is trying to run the TFS to TFS Migration Tool. Alas, when I run the migration tool only a small fraction of the code gets migrated and the migration tool's log is loaded with messages...

TfsMigrationWindowsServiceHost.exe Information: 0 : TF14045: The identity <3rd party domain>\<3rd party username> is not a recognized identity. LogicalOperationStack=Migrate ThreadId=8 DateTime=2009-03-17T15:14:08.6591468Z TfsMigrationWindowsServiceHost.exe Information: 0 : Unable to checkin to TFS using the identity <3rd party domain>\<3rd party username>. Converting to default credentials. LogicalOperationStack=Migrate ThreadId=8 DateTime=2009-03-17T15:14:08.6591468Z TfsMigrationWindowsServiceHost.exe Information: 0 : VCSession_2009_03_17_09_59_03_627: TF10141: No files checked in: resolve the conflicts and try again. LogicalOperationStack=Migrate ThreadId=8 DateTime=2009-03-17T15:14:08.9247718Z TfsMigrationWindowsServiceHost.exe Warning: 0 : TF10141: No files checked in: resolve the conflicts and try again. LogicalOperationStack=Migrate ThreadId=8 DateTime=2009-03-17T15:14:08.9247718Z TfsMigrationWindowsServiceHost.exe Information: 0 : Microsoft.TeamFoundation.VersionControl.Client.CheckinException: TF10141: No files checked in: resolve the conflicts and try again. at Microsoft.TeamFoundation.VersionControl.Client.Workspace.ReportCheckInConflictsAndThrow(Failure[] failures) at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckInInternal(String author, PendingChange[] changes, String comment, CheckinNote checkinNote, WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride, CheckinOptions checkinOptions) at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(PendingChange[] changes, String author, String comment, CheckinNote checkinNote, WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride, CheckinOptions checkinOptions) at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(PendingChange[] changes, String author, String comment, CheckinNote checkinNote, WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride) at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(PendingChange[] changes, String comment, CheckinNote checkinNote, WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride) at Microsoft.TeamFoundation.Migration.Toolkit.VC.SourceToTfsMigrationEngine.Checkin(ChangeGrouping group, Int32& changesetId) at Microsoft.TeamFoundation.Migration.Toolkit.VC.SourceToTfsMigrationEngine.ProcessChangeGroup(ChangeGrouping group) at Microsoft.Vsts.Rangers.Migration.TfsToTfs.TfsToTfsMigrationEngine.ProcessChangeGroup(ChangeGrouping group) LogicalOperationStack=Migrate ThreadId=8 DateTime=2009-03-17T15:14:08.9403968Z

The above message can be found 100s of times in the log. I am guessing this 'identity' issue is the reason why the vast majority of files are not migrated over. But then again I would have thought ALL files would have had this problem...including the few that were migrated over.

I've found very little specific information about 'TF14045' and 'TF10141'. I get the impression that the problem is due to the fact that file checkins on the 3rd party TFS environment are associated with users specific to that domain and are not found in our domain. So...

Does anyone who is familiar with the TFS to TFS Migration Tool have any idea what the problem might be?

Can anyone think of a way around this situation so that the new TFS machine doesn't freak out when users of the other domain are linked to files being migrated to the new environment? I did try adding the problem '<3rd party domain>\<3rd party username>' to the new TFS environment but TFS couldn't find that user and wouldn't add them.

Better yet...if anyone knows how I'd love to know how to do the backup and restore migration method using different SQL Server versions.

2
I've had quite quick responses in the past when mailing the contacts for the tool in codeplex, suggest doing that...Ruben Bartelink

2 Answers

0
votes

i dont know if this helps but you can try setting up inter domain trust , so you can login with users from both domains.

0
votes

I solved my issue by solving the problem manually in the workspace and then providing the check-in number as the "Source Version" to resolve the conflict...

TFS Integration Tools – Issue: TF10141 No Files checked in as a result of a TFS check-in failure