Есть ли обходной путь, когда TFPT «не может определить рабочее пространство» и обновление кеша не работает?

Question

У меня проблемы с тем, чтобы TFPT.exe работал вообще, даже после попытки обновить настройки кэшированного рабочего пространства в соответствии с обычными рекомендациями в Интернете. Смотрите ниже для журнала, представляющего то, что я пробовал и вижу. Может кто-нибудь объяснить, почему «tf get» может определить рабочее пространство, но «tfpt annotate» не удается?

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

Когда я редактирую рабочее пространство в Visual Studio 2010, сетка «Рабочие папки» содержит 3 строки, одна из которых «Active, $ / Foo, C: \ tfsproj», поэтому я предполагаю, что папка сопоставлена ​​правильно.

перекрестная публикация на Team Foundation Server - Электроинструменты и дополнения

Answer 1

Это предложение от аналогичное обсуждение на форумах MSDN помогло мне:

Вы должны убедиться, что вы выполняете команды из сопоставленных Папка , вы можете запустить tf workfold, чтобы увидеть, сопоставлена ​​ли текущая папка или нет (т. е. в вашем случае запустите команды с C:\Temp)

Answer 2

У меня была та же ошибка, и проблема заключалась в том, что когда я запускал tfpt из командной строки, он преобразовывался в версию электроинструментов 2008 года вместо версии 2010 года.

Запустите tfpt без аргументов ив справке, которую он выдает, он сообщает, какая это версия.

Answer 3

Для тех, кто в vs2017: попробуйте запустить vs2015 (не 2017), обязательно подключитесь к TFS-серверу в vs2015, а затем tfpt заработал просто отлично.

Но обратите внимание: звучит так, как будто команды tf powertools интегрированы в новый инструмент tfs, поэтому tfpt не очень-то важен в 2017 году. См. Ответ Даниэля Манна здесь для получения дополнительной информации и полезных ссылок: tfpt.exe в Visual Studio 2017

Answer 4

После нового взгляда на это оказывается, что 'C: \ tfsproj' является символической ссылкой каталога на 'C: \ some \ nested \ path'. Выполнение команды TFPT из вложенного пути работает должным образом.

Интересно, что рабочее пространство TFS было сопоставлено с вложенным путем, поэтому удивительно, что команды TF (например, tf get / preview) могли корректно работать из псевдонима.

Я подозреваю, что TFPT неправильно определяет символические ссылки на каталоги NTFS при определении рабочей области.

Answer 5

Пока вы находитесь в рабочем каталоге, tfpt annotate должен работать.Если вы получаете сообщение «Невозможно определить рабочее пространство», это проблема кэширования.

Если, как вы сказали, вы запустили tf workspaces / s: serverURL и он по-прежнему не разрешается, я бы попытался создать новое рабочее пространство и протестировать его там.Если это работает, то что-то не так с рабочей областью, очевидно, и я просто удалил бы ее и использовал новую.Если оба не удаются, то, конечно, есть более серьезная проблема, но именно так я бы к ней подошел.

Answer 6

В моем случае, вот как я пришел к этой проблеме (сообщение об ошибке «Невозможно определить рабочее пространство» ) и как я решил ее.

Прибытие:

У меня был какой-то код. Разработка перешла из ветви, в которой я работал (назовем это Branch1 ), в Branch2 . Я должен был продолжить под Branch2 . Я отложил изменения, заново сопоставил мою папку для разработки с Branch2 , открыл Командная строка разработчика для VS2012 и выполнил следующую команду

tfpt unshelve / migrate / source: "$ / path / Branch1" / target: "$ / path / Branch2" "Имя набора полок"

Здесь у меня есть сообщение "Невозможно ..."

Решение:

В моем случае проблема заключалась в том, что когда я открывал командную строку, ее рабочий каталог был c:\program files\...\...Visual Studio 11.... Это сработало (мигрировав shelveset), когда я сменил рабочий каталог на каталог самого филиала: c:\MyBranchFolder