2009-03-17 7 views
3

Un tiers a développé des applications pour nous et utilise MS Team Foundation Server 2008 pour leur contrôle de source. Ma société a récemment installé notre environnement TFS 2008 et nous essayons de migrer le code source du développeur tiers TFS vers notre machine TFS. Vous avez d'abord pensé essayer la méthode de sauvegarde et de restauration de la migration, mais le seul serveur SQL disponible est une licence Standard Edition et SQL Server du développeur tiers utilisé pour TFS est Enterprise Edition. Ce qui signifie que la méthode de sauvegarde et de restauration ne fonctionnera pas. Donc j'ai essayé d'obtenir l'outil de migration de TFS à TFS (trouvé sur codeplex) migrer le code source. Malheureusement, j'ai eu des problèmes ...Outil de migration TFS vers TFS - problèmes de domaine

Le réseau de développeurs tiers est dans son propre sous-réseau au sein du réseau de notre société. Et ils ont leur propre domaine séparé de nous. Donc, leur machine TFS est sur leur domaine, notre machine TFS est dans un autre domaine, et mon PC (qui a VS, Team Explorer, les outils TFS Power ...) est connecté aux deux réseaux et tente d'exécuter le TFS à la migration TFS Outil. Hélas, quand je lance l'outil de migration seule une petite fraction du code est migré et le journal de l'outil de migration est chargé avec des messages ...

TfsMigrationWindowsServiceHost.exe Information: 0: TF14045: L'identité < de domaine 3ème partie > \ < Le nom d'utilisateur tiers> n'est pas une identité reconnue. LogicalOperationStack = Migrate ThreadId = 8 DateTime = 2009-03-17T15: 14: 08.6591468Z TfsMigrationWindowsServiceHost.exe Information: 0: Impossible de checkin à TFS en utilisant l'identité < domaine 3ème partie> \ < username 3ème partie>. Conversion aux informations d'identification par défaut. LogicalOperationStack = Migrate ThreadId = 8 DateTime = 2009-03-17T15: 14: 08.6591468Z TfsMigrationWindowsServiceHost.exe Information: 0: VCSession_2009_03_17_09_59_03_627: TF10141: Aucun Démarré: résoudre les conflits et essayez à nouveau. LogicalOperationStack = Migration ThreadId = 8 DateTime = 2009-03-17T15: 14: 08.9247718Z TfsMigrationWindowsServiceHost.exe Avertissement: 0: TF10141: Aucun fichier archivé: résolvez les conflits et réessayez. LogicalOperationStack = Migrate ThreadId = 8 DateTime = 2009-03-17T15: 14: 08.9247718Z TfsMigrationWindowsServiceHost.exe Information: 0: Microsoft.TeamFoundation.VersionControl.Client.CheckinException: TF10141: Aucun Démarré: résoudre les conflits et réessayer. à Microsoft.TeamFoundation.VersionControl.Client.Workspace.ReportCheckInConflictsAndThrow (échec [] échecs) à Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckInInternal (auteur String, PendingChange [] modifications, commentaire String, CheckinNote checkinNote, WorkItemCheckinInfo [] workItemChanges, PolicyOverrideInfo policyOverride, checkinOptions checkinOptions) à Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn (PendingChange [] changements, auteur String, commentaire String, CheckinNote checkinNote, WorkItemCheckinInfo [] workItemChanges, PolicyOverrideInfo policyOverride, checkinOptions checkinOptions) chez Microsoft Changements .TeamFoundation.VersionControl.Client.Workspace.CheckIn (PendingChange [], Auteur de chaîne, Commentaire de chaîne, CheckinNote checkinNote, WorkItemCheckinInfo [] workItemChanges, PolicyOverrideInfo policyOverride) à Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn (PendingChange [] modifications, Commentaire de chaîne, CheckinNote checkinNote, WorkItemCheckinInfo [] workItemChanges, PolicyOverrideInfo policyOverride) à Microsoft.TeamFoundation.Migration.Toolkit.VC.SourceToTfsMigrationEngine.Checkin (ChangeGrouping groupe, Int32 & changesetId) à Microsoft.TeamFoundation.Migration.Toolkit.VC.SourceToTfsMigrationEngine.ProcessChangeGroup (groupe ChangeGrouping) à Microsoft.Vsts.Rangers.Migration.TfsToTfs.TfsToTfsMigrationEngine.ProcessChangeGroup (groupe ChangeGrouping) LogicalOperationStack = Migrate ThreadId = 8 = DateTime 2009-03-17T15: 14: 08.9403968Z

Le message ci-dessus peut être trouvé 100s de fois dans le journal. Je suppose que cette question d'identité est la raison pour laquelle la grande majorité des fichiers ne sont pas migrés. Mais là encore j'aurais pensé que TOUS les fichiers auraient eu ce problème ... y compris les quelques qui ont été migrés. J'ai trouvé très peu d'informations spécifiques sur TF14045 et TF10141. J'ai l'impression que le problème est dû au fait que les vérifications de fichiers sur l'environnement TFS tiers sont associées à des utilisateurs spécifiques à ce domaine et ne sont pas trouvées dans notre domaine. Donc ...

Est-ce que quelqu'un qui est familier avec l'outil de migration TFS vers TFS a une idée de ce que pourrait être le problème?

Quelqu'un peut-il penser à un moyen de contourner cette situation afin que la nouvelle machine TFS ne panique pas lorsque les utilisateurs de l'autre domaine sont liés à des fichiers en cours de migration vers le nouvel environnement? J'ai essayé d'ajouter le problème '< 3rd party domain> \ < 3ème nom d'utilisateur>' au nouvel environnement TFS mais TFS n'a pas pu trouver cet utilisateur et ne les a pas ajoutés.

Mieux encore ... si quelqu'un sait comment j'aimerais savoir comment faire pour sauvegarder et restaurer la méthode de migration en utilisant différentes versions de SQL Server.

+0

J'ai eu tout à fait réponses rapides dans le passé lors de l'envoi des contacts pour l'outil dans codex, suggèrent de faire cela ... –

Répondre

0

Je ne sais pas si cela aide, mais vous pouvez essayer de configurer l'approbation inter-domaine, de sorte que vous pouvez vous connecter avec des utilisateurs des deux domaines.

Questions connexes