Je ne parviens pas à faire fonctionner TFPT.exe, même après avoir tenté d'actualiser les paramètres de l'espace de travail mis en cache conformément aux conseils habituels sur Internet. Voir ci-dessous pour un journal représentant ce que j'ai essayé et ce que je vois. Quelqu'un peut-il expliquer pourquoi "tf get" est capable de déterminer l'espace de travail, mais que "tfpt annotate" échoue?
C:\tfsproj> set tfptcmd="C:\Program Files (x86)\Microsoft Team Foundation Server 2010 Power Tools\TFPT.exe"
C:\tfsproj> set tfcmd="C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\TF.exe"
C:\tfsproj> %tfcmd% workspaces /s:http://tfs:8080/tfs/Apps
Collection: tfs\Apps
Workspace Owner Computer Comment
--------- -------------- -------- ---------------------------------------------
DAVID David_Zarlengo DAVID
C:\tfsproj> %tfcmd% get /preview
C:\tfsproj\src\:
Replacing Readme.txt
C:\tfsproj> %tfptcmd% annotate src\Readme.txt
Unable to determine the workspace
Lorsque je modifie l'espace de travail dans Visual Studio 2010, la grille "Dossiers de travail" contient 3 lignes, dont l'une est "Actif, $/Foo, C:\tfsproj". Par conséquent, je suppose que le dossier est correctement mappé.
cross-posted sur Team Foundation Server - Outils électriques et modules complémentaires
Après un nouveau regard sur cela, il s’avère que "C:\tfsproj" est un lien symbolique de répertoire vers "C:\some\nested\path". L'exécution de la commande TFPT à partir du chemin imbriqué fonctionne comme prévu.
Fait intéressant, l’espace de travail TFS a été mappé sur le chemin imbriqué. Il est donc surprenant que les commandes TF (par exemple, tf get/preview) puissent fonctionner correctement à partir du chemin d’alias.
Je soupçonne que TFPT ne suit pas correctement les liens symboliques des répertoires NTFS lors de la détermination de l'espace de travail.
Cette suggestion de une discussion similaire sur les forums MSDN m'a aidé à:
Vous devez vous assurer que vous êtes en exécutant les commandes depuis un dossier dossier mappé} =, Vous pouvez exécuter
tf workfold
pour voir si le dossier actuel est mappé Ou non. (ie dans votre cas, lancez les commandes deC:\Temp
)
J'ai eu cette même erreur et le problème était que lorsque j'ai exécuté tfpt à partir de la ligne de commande, cela résolvait la version 2008 des outils électriques au lieu de la version 2010.
Exécutez tfpt sans argument et, dans l’aide fournie, il indique quelle version il s’agit.
Pour ceux de vs2017: essayez d'allumer vs2015 (pas 2017), assurez-vous de vous connecter au serveur TFS dans vs2015, puis tfpt a très bien fonctionné.
Mais remarque: il semble que les commandes tf powertools soient intégrées au nouvel outil tfs. Tfpt n'est donc pas vraiment une chose en 2017. Voir la réponse de Daniel Mann ici pour plus d'informations et des liens utiles: tfpt.exe sur Visual Studio 2017
Tant que vous êtes dans le répertoire de travail, tfpt annotate devrait fonctionner. Si vous obtenez le message "Impossible de déterminer l'espace de travail", il s'agit d'un problème de mise en cache.
Si, comme vous l'avez dit, vous avez exécuté tf workspace/s: serverURL et que cela ne résout toujours pas le problème, j'essaie de créer un nouvel espace de travail et de le tester. Si cela fonctionne, il est évident que quelque chose ne va pas dans l'espace de travail et je voudrais simplement le supprimer et utiliser le nouveau. Si les deux échouent, il y a bien sûr un problème plus grave, mais c’est comme cela que je l’approcherais.
Dans mon cas, voici comment je suis arrivé à ce problème (message d'erreur "Impossible de déterminer l'espace de travail" ) et comment je l'ai résolu.
Arrivée:
J'ai eu du code. Le développement est passé de la branche dans laquelle j'ai travaillé (appelons-le Branch1 ) à Branch2 . Je devais continuer sous Branch2 . J'ai mis les modifications en mémoire, remappé mon dossier de développement sur Branch2 , ouvert Invite de commandes du développeur pour VS2012 et exécuté la commande suivante
tfpt unshelve/migrate/source: "$/chemin/branche1"/cible: "$/chemin/branche2" "nom du plateau"
Ici, j'ai le message "Impossible ..."
Solution:
Dans mon cas, le problème était que lorsque j'ai ouvert l'invite de commande, son répertoire de travail était c:\program files\...\...Visual Studio 11...
. Cela fonctionnait (migration du plateau) lorsque j'ai changé le répertoire de travail dans le répertoire de la branche elle-même: c:\MyBranchFolder