Team Foundation Server de Déplacement de la Source avec l'Histoire

Je me demandais quelle est la meilleure approche pourrait être de déplacer le code source, à l'histoire, à partir d'un Projet d'Équipe à l'autre de l'Équipe de Projet. Je ne suis pas concerné avec des éléments de travail, des rapports, ou des sites SharePoint, comme le système que nous allons être la restauration de ne pas utiliser ces fonctionnalités. La raison de vouloir passer à un autre de l'Équipe de Projet est aussi motivée par le fait qu'à l'origine de la mise en œuvre (en cours de restauration à partir d'une sauvegarde qui a été maintenue par un tiers) ont été à l'aide d'un tiers d'un modèle de processus que nous ne souhaitons pas utiliser à l'avenir. Nous voulons commencer d'utiliser l'élément de travail de suivi et de reporting une fois la migration terminée.

La TFS Plate-forme d'Intégration semble être un scénario probable. Il peut être utilisé pour modifier le modèle de processus, conformément à la documentation. Cependant, j'ai été curieux de savoir si les tf.exe déplacer la syntaxe pourrait fonctionner? Quelque chose comme:

tf.exe déplacez $/ProjectA $/Projetb

C'est ma compréhension que cette commande fonctionne beaucoup comme une opération de changement de nom, alors que le déplacement avec le "Déplacer" du menu contextuel de l'élément dans l'Explorateur du Contrôle de Source est plus comme un supprimer et ajouter de l'opération. Aussi, serait le tf.exe déplacer chemin fait d'associer le code sous les dossiers avec l'Équipe Projet, en supposant que $/ProjectA est la racine de la source de contrôle de dossier pour un projet et $/Projetb est la racine de la source de contrôle de dossier pour les autres? La clé est d'être en mesure de préserver l'histoire, si possible.

Des conseils ou des conseils seraient grandement appréciés!

Edit - Pourrait branchement à un autre projet de gérer ce scénario - un peu comme Microsoft explique dans le La Ramification Des Conseils de la documentation? Je pense que cela pourrait être la réponse, car l'histoire serait susceptible d'être conservé avec la direction générale. Cependant, je n'ai pas accès à un Serveur Team Foundation server 2008 instance au moment de le tester.

InformationsquelleAutor Joseph Ferris | 2010-02-07

tfs version-control

38

Déplacer et Renommer sont des alias. Il n'y a absolument aucune différence, dans n'importe quelle version de TFS, à partir de la ligne de commande ou l'INTERFACE utilisateur.

À la fois de préserver leur histoire. Au moins dans 2005/2008, vous gardez le même élément de la VersionedItem table n'importe comment, souvent, ou comment considérablement le nom et/ou le parent changements de chemin d'accès. Il n'y a effectivement aucun moyen d'obtenir un "faux" renommer (delete + ajouter), sans beaucoup de travail manuel de votre part.

Cependant, bien que ce modèle versioning est très pur, d'un point de vue théorique, il a une certaine pratique de pièges. Parce que les différents éléments peuvent occuper le même nom à différents points dans le temps, TSF a besoin du nom complet + version pour identifier de façon unique toutes les entrées de vous l'envoyer. Normalement, vous ne remarquez pas cette restriction, mais une fois que vous avez renommé éléments dans le système, si vous dites tf [doSomething] $/newname -version:oldversion ensuite, il aura de la confusion et jeter une erreur ou d'opérer sur un élément que vous ne pouvez pas avoir l'intention. Vous devez être prudent de passer des combinaisons valides (newname+nouvelleversion ou oldname+oldversion) pour assurer les commandes se comportent de la façon dont vous le souhaitez.

TFS 2010 changements de l'histoire un peu: c'est une branche+suppr sous les couvertures, causant la itemID à changer. De même, tous les jours des commandes Get et l'Histoire sont "truquées" très bien; les anciens clients sont environ 95% compatible. L'avantage est que lorsque vous avez plusieurs renomme dans le système et le chemin élément basé sur les recherches commencent à devenir ambigu comme mentionné ci-dessus, le serveur va accepter simplement le nom que vous spécifiez et de courir avec lui. Cela améliore les performances globales du système et élimine plusieurs pièges qu'inconnue utilisateurs se situent souvent dans, au prix de ne pas être aussi souple et de ne pas conserver d'historique avec 100% de précision (par exemple, quand il y a des collisions de nom lors d'une Fusion de deux branches).

De retourner le problème à portée de main...

Il n'est pas aussi simple que de dire tf renommer $/projectA $/projetb. Dossiers de niveau supérieur dans le contrôle de la source de l'arbre sont réservés à l'Équipe de l'Assistant de Création de Projet; vous ne pouvez pas exécuter standard tf commandes contre eux. Ce que vous avez besoin est un script comme:
```
Get-TfsChildItem $/ProjectA |
    select -Skip 1 |  # skip the root dir
    foreach {
        tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")
    }
```
[bien sûr, vous pouvez le faire à la main si il n'y a pas trop d'enfants de moins de $/ProjectA]

Autant que les astuces que j'ai mentionné, je vais élaborer sur une droite maintenant, depuis la recherche de vieux de l'histoire semble très important pour vous. Une fois que vous checkin les renommer, tf histoire $/ProjectA/somefile.cs ne fonctionnera PAS. Par défaut, tf commandes supposent version = "plus tard". L'une de ces alternatives sera le plein de l'histoire que vous voulez:
- tf histoire $/ProjectA/somefile.cs;1234 où révision 1234 était avant le déménagement
- tf histoire $/Projetb/somefile.cs;5678 où révision 5678 était après le déménagement. Ou vous pouvez simplement omettre la version.
Une dernière alternative pour l'exhaustivité & des fins de débogage:
- tf histoire $/ProjectA/somefile.cs -slotmode. Vous verrez seulement les changements qui sont survenus avant le déménagement; cependant, vous verrez aussi l'histoire de tous les autres éléments qui peuvent avoir vécu dans l' $/ProjectA/somefile.cs "slot" avant ou après l'élément que vous avez déplacé sous B.
(Dans TFS 2010, "sous le mode" est le comportement par défaut; il y a un -ItemMode option pour demander à ce que votre recherche se retrouve à travers l'histoire, comme il a été 2008 plutôt que basé sur le chemin.)

EDIT - non, la ramification est pas une très bonne alternative. Alors que la ramification ne laisser suffisamment de métadonnées dans le système de retracer l'historique complet de tous & à partir de Projetb, il n'est pas très convivial en 2008. Prévoyez de passer beaucoup de temps à l'apprentissage de la tf fusionne commande (pas d'équivalent de l'INTERFACE utilisateur). 2010 améliore considérablement votre capacité à visualiser les changements à travers de multiples branches, mais ce n'est toujours pas propre expérience unifiée, vous obtiendrez à partir d'un changement de nom.
- Wow, Richard. Absolument fantastique de l'information. Je vais essayer dans mon laboratoire de test de demain. Vous aviez mentionné le script parce que la racine est réservée. Si je faisais le renommer à partir d'un dossier qui a été d'un niveau en dessous de la racine, j'ai pu omettre le script, puis - corriger? De toute façon - la réponse impressionnante. Je vous remercie pour votre temps!
- Ouais. L'idée de base est de renommer ProjectA\dossier1 -> Projetb\dossier1, ProjectA\dossier2 -> Projetb\dossier2, etc. Le script est juste pour gagner du temps & effort dans le cas où vous avez 50 fichiers & dossiers dedans.
- Excellent. Je vous remercie beaucoup pour faire de ce clair et facile à comprendre!
- Bonjour Richard, merci pour votre script. Je me demande vraiment comment je peux exécuter cette? Dans mon VS Console, je n'arrive pas à exécuter ce...
- Si ProjectA est supprimé après le déménagement, ne sera pas toute l'histoire qui sont reportées à Projetb également disparaître des éléments déplacés sur Projetb?
InformationsquelleAutor Richard Berg
17

Richard réponse ci-dessus est bien écrit et explique bien la situation. J'ai eu un couple de plus pratique gotcha d'ajouter, cependant.

Dans TFS2010, le comportement par défaut rend semblent comme le déplacement d'un fichier entraîne la perte de toute l'histoire d'avant le déplacement. La commande de mes utilisateurs sont susceptibles de les utiliser (et celle qui est utilisée, il semble, par la VS2010 GUI) est:
```
tf history $/ProjectB/somefile.cs
```
Mes utilisateurs ont l'intention d'obtenir toute l'histoire de somefile.cs, à la fois avant et après le déménagement. Ils veulent "l'histoire du code qui est actuellement stocké dans $/Projetb/somefile.cs", quel que soit le nom du fichier à n'importe quel point dans le temps. Peut-être que d'autres personnes voient les choses différemment.

La première chose à corriger, c'est que l'interface graphique qui s'affiche pour moi dans VS2010 à l'aide de TFS2010 initally montre seulement l'histoire depuis le déménagement. Les moins récentes élément de la liste est l'opération de changement de nom. Il peut être étendu avec une subtile petite flèche de la liste déroulante. Voici ci-dessous l'histoire de l'emplacement précédent. Si vous ne savez pas de regarder pour cela, il peut ressembler à votre histoire est allé.

Le deuxième piège est que si plus tard vous souhaitez supprimer ProjectA (parce que vous avez terminé la migration de Projetb, par exemple), l'histoire est vraiment terminé. L'expansion de la liste déroulante dans l'histoire pour $/Projetb/somefile.cs n'est pas de produire le plus âgé de l'histoire.
- Merci de remarquer le danger de la suppression de "ProjectA" et comment il affecte le visuel de l'histoire.
- Merci pour le "moins récent" liste via la petite flèche à gauche de l'id de Révision. Je pensais que j'avais perdu toute mon histoire 🙁
InformationsquelleAutor solublefish
2

Une autre option (et je pense plus facile) est l'importation de Git puis exporter retour à TFS à l'aide de Git-TF outils de ligne de commande.
- Install Git-TF binaire, Choclatey ou de code source.
- Clone TFS dossier:
git tf clone https://myAcc.visualstudio.com/mycollection $/TeamProjectA/Main --deep
- Dissocier le Repo Git du serveur TFS par la suppression de la .Git/tf dossier et le .Git/git-tf fichier.
- Configurer le nouveau Repo Git pour se connecter à un vide TFS dossier.
git tf configure https://myAcc.visualstudio.com/mycollection $/TeamProjectB/Main --deep
- N'oubliez pas le --deep
git tf pull

Vous devriez obtenir un message à ce point "git-tf: c'est une nouvelle configuration de référentiel. Il n'y a rien à chercher à partir de tfs."

git commit -a -m "merge commit"

git tf checkin --deep
- Chers david004. J'ai essayé ce et le code de l'histoire est maintenu, mais tous les timestamps sont mis à aujourd'hui, et tous les utilisateurs sont changé en moi. Est-ce que cela fonctionne ou bien suis-je raté quelque chose?
- Oui, c'est une nuisance. Je ne sais pas comment cela peut être évité, bien que je soupçonne une sorte de contrôle de version ninja pourrait écrire un script pour TFS que des extraits et insère la date et l'auteur de l'info.
- les horodatages dans TFS sont conçus pour la vérification de l'intégrité. Si vous ou d'autres mortels essaie d'ajuster les dates ou les heures de la TSF de la base de données deviendra probablement corrompu ou autrement non approuvée par la TSF services (rendu inutilisable). Je m'attends à un TFS maître ninja peut-être capable de faire craquer n'importe quel vérification de l'intégrité... mais ne vous attendez pas les horodatages pour être inviolable "par des moyens normaux" (par un audit ISO 27001/respect de la terminologie). S'il vous plaît commentaire ici si vous prouver le contraire (avec exemple de script 🙂 ). Cheers!
InformationsquelleAutor david004
0

Concernant la commande d'origine ci-dessus: -
```
Get-TfsChildItem $/ProjectA |
    select -Skip 1 |  # skip the root dir
    foreach {
        tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")
    }
```
À la fois la source et la cible noms doivent être entourés par des guillemets dans le cas où il y a un espace en plein pathfilename. Je l'ai trouvé difficile à faire sur $_.ServerItem comme l'entourant avec échappé à la " les retours que tout enfant de l'objet et non pas seulement l' .serverItem chaîne. Ou si j'ai réussi à obtenir de la chaîne, j'ai eu des retours chariot indésirables tels que

"

$proj/dossier/fichier

"

Finalement, j'ai fait la commande à travailler avec la suite, mais j'ai trouvé que l'histoire n'est toujours pas de transfert, qui a été le point de l'ensemble! Je pense donc que cette commande est l'équivalent direct de simplement à l'aide d'un clic droit de la souris dans l'explorateur de source et en sélectionnant renommer (ou déplacer).
```
$tfsServerString = "http://machine:8080/tfs/DefaultCollection"
$tfs = Get-TfsServer $tfsServerString
Get-TfsChildItem -server $tfs "$/Dest Project/MyTestProject" | select -Skip 1 | foreach { $sourceName = $_.serveritem; $targetName = $_.serveritem.replace("$/Dest Project/MyTestProject/", "$/Dest Project/Source/StoreControllers/dSprint/dSprint2/") ; ./tf rename `"$sourceName`" `"$targetName`" /login:myUser }
```
Noter également, elle requiert l'utilisation de la backtick échapper "

InformationsquelleAutor Philip Beck

Vous devez vous connecter pour publier un commentaire.