Ошибка Team Build: путь… уже сопоставлен с рабочим пространством


162

При создании новой сборки в Team Foundation Server я получаю следующую ошибку при попытке запустить новую сборку:

Путь C: \ Build \ ProductReleases \ FullBuildv5.4.2x \ Sources уже сопоставлен с рабочей областью BuildServer_23.

Я не вижу рабочую область с таким именем в диалоговом окне рабочих областей.


Это более сложная ошибка, см. Другой вопрос .
psulek

Ответы:


138

Используйте утилиту командной строки TF - Team Foundation Version Control Tool ( tf ).

Вы можете получить список всех рабочих областей, открыв командную строку Visual Studio, затем перейдя в папку рабочей области и выполнив следующие команды:

C:\YourWorkspaceFolder>tf workspaces /owner:*

Вы должны увидеть свою проблемную рабочую область в списке, а также ее владельца.

Вы можете удалить рабочее пространство с помощью следующей команды:

C:\YourWorkspaceFolder>tf workspace /delete /server:BUILDSERVER WORKSPACENAME;OWNERNAME

16
Я получаю сообщение "Невозможно определить сервер управления исходным кодом". при запуске рабочих областей tf на сервере сборки. Любые идеи, как это исправить?
Корвин

9
Корвин: запустите команду из папки, которая является частью рабочей области
Raj Rao

18
Оставьте аргумент / server, он не нужен. В противном случае хороший ответ!
techphoria414

1
Отличный ответ, единственное, что я хотел бы добавить, это то, что вам может потребоваться войти в TFS как владелец рабочей области, или вы можете получить ошибку об отказе в разрешении.
JMK

5
После / delete я ввел "/ collection: http: <server>: 808 / tfs / <collection> ..._ then_ имя рабочего пространства; владелец рабочего пространства ... работал как ожидалось. Моя проблема была связана с повторным созданием определения сборки с помощью то же имя.
efisher

44

Просто удалите содержимое следующих папок:

C: \ Users \ Имя пользователя \ AppData \ Local \ Microsoft \ Team Foundation \ 3.0 \ Cache

Где UserName - фактический или текущий пользователь, а 3.0 - номер версии.


Этот ответ был дан уже несколько раз, с более подробным объяснением, пару раз назад.
Эндрю Барбер

это то, что мне было нужно Я удалил все ссылки с помощью команды tf, а также со сторонниками, но мне все еще нужно было удалить этот кеш. спасибо, спасибо, спасибо
GrahamJRoy

1
В частности, вы можете удалить WorkspaceInfoзапись рабочей области нарушителя из C:\Users\ukcco3jbe\AppData\Local\Microsoft\Team Foundation\3.0\Cache\VersionControl.config. XPath:/VersionControlServer/Servers/ServerInfo/WorkspaceInfo
JohnLBevan

C: \ Users \ Имя пользователя \ AppData \ Local \ Microsoft \ Team Foundation \ 8.0 для vs2019
Серхио Вильялобос

30

Я получил эту ошибку, которая была вызвана наличием двух определений сборки, указывающих на один и тот же источник. Проблема заключалась в том, что я использовал статический каталог сборки в агенте сборки.

Этот пост на форуме точно описывает мою проблему и ее решение: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/60a4138a-9b28-4c46-bdf4-f9775ce43c3e/


28

У меня была похожая проблема, и чтобы удалить рабочую область, которая вызывала у меня проблему, я вошел на другой компьютер с установленным клиентом TFS и выполнил следующее:

  • На Файл меню, выберите пункт Control Source , Advanced , а затем нажмите Workspaces ... .
  • В диалоговом окне « Управление рабочими пространствами » установите флажок « Показать удаленные пакеты» .
  • В столбце « Имя» выберите рабочую область, которую вы хотите удалить, и нажмите « Удалить» .
  • В диалоговом окне подтверждения нажмите кнопку ОК .

3
Моя рабочая станция была указана дважды. Удалил дубликат и он сразу заработал. Спасибо.
Кайл Хэнкок

26

У нас была та же проблема, но удаление рабочего пространства с сервера TFS не сработало. (Должен отметить, что я взял виртуальную машину своих коллег, которая уже была настроена с его учетными данными.)

Для меня это сработало: http://blogs.msdn.com/b/buckh/archive/2006/09/12/path-is-already-mapped-in-workspace.aspx

Я просто зашел в: ... \ Local Settings \ Application Data \, выполнил поиск VersionControl.config, открыл папку с этим файлом и удалил все его содержимое.

До этого я пытался вручную редактировать файл, но он продолжал с тем же сообщением об ошибке.

Надеюсь, это поможет.


4
Был полезен для нашей ситуации, когда мы переключали серверы, а старый сервер больше не существовал, но на старой машине все еще были настройки для него.
Джоэл Рондо

Я должен был сделать это тоже. Я удалил всю Local Settings\Application Data\Microsoft\Team Foundationпапку, и все было хорошо потом
Орион Эдвардс

Это кеш, просто удалите папку (и) кеша
Curios

Я удалил рабочее пространство и папку кеша, но проблема все еще существует. Может быть, jenkins работает под другим пользователем и использует другой кеш?
ideafixxxer

Это, вероятно, так и есть! Существуют всевозможные плагины, которые вы можете использовать для очистки вашего рабочего пространства перед началом фактической сборки. Если вы найдете ответ на эту конкретную проблему, вернитесь и
опубликуйте

16

По какой-то причине у меня возникли проблемы с удалением рабочего пространства из утилиты командной строки. К счастью, я нашел Team Foundation Sidekicks 2010 (из этого поста ), который является бесплатным и предоставляет графический интерфейс для просмотра и удаления рабочих областей TFS, а также многие другие полезные функции TFS.


2
Я настоятельно рекомендую всем, кто работает с TFS, взглянуть на TFS Sidekicks, потому что он бесплатный и имеет много действительно обязательных функций.
Alkampfer

6

У меня была похожая проблема с Visual Studio 2010, которая жаловалась на уже отображенное рабочее пространство, но вместо удаления всего рабочего пространства я использовал следующее из командной строки Visual Studio: «tf workspace PROBLEM_WORKSPACE_NAME». Это вызвало диалог «Edit Workspace». Оттуда я смог удалить нужный путь из списка «Рабочие папки», который избавился от ошибки.


Ваше решение помогло мне в аналогичном случае. Я создал рабочее пространство не для того пользователя, поэтому я удалил его, а затем попытался создать его для правильного, но tfпожаловался, что путь был связан с другим рабочим пространством - тем, которое я удалил. Вдохновленный вашим ответом, я заново создал рабочее пространство для не того пользователя, удалил только связь с путем и, наконец, мне удалось создать рабочее пространство для правильного пользователя.
Edymtt

5

Остальное было довольно легко.

Просто перейдите в эту папку: C: \ Users {Имя пользователя} \ AppData \ Local \ Microsoft \ Team Foundation \ 4 \ Cache и удалите все, что находится в этой папке.


5

Я получил исключение, сообщающее, что файл уже сопоставлен в другом рабочем пространстве: «Путь {Путь к файлу} уже сопоставлен в рабочем пространстве {Имя рабочего пространства}».

Это рабочее пространство было удалено до . С помощью моего друга я обнаружил, что TFS сохраняет информацию о рабочей области в папке с локальными настройками пользователя dir. Мы нашли файл с именем:

VersionControl.config под {Документы пользователя и директории Настройки} \ Local Settings \ Application Data \ Microsoft \ Foundation Team \ 1.0 \ Cache. Этот файл содержит все локальные сопоставления TFS. Вероятно, когда вы используете метод Map и не используете: public void DeleteMapping (отображение WorkingFolder); перед удалением рабочей области информация о сопоставлении не удаляется из этого файла, который используется TFS для проверки того, что вы уже сопоставили конкретный путь.

Чтобы решить эту проблему, удалите все ключи из файла конфигурации. Не удаляйте файл, потому что вы снова получите его из кэша сервера.


4

Вот что я сделал (хорошо, что я делаю):

С помощью TFS Sidekicks очистите фильтры пользователя и сервера, чтобы они были пустыми. Это позволит вам получить все рабочие пространства.

Проверьте ошибку сборки для имени рабочей области. В случае с OP это BuildServer_23. В моей среде это отличается, но в основном просто сопоставьте имя ошибки с тем, которое указано в списке помощников tfs.

Нажмите на красный крестик, чтобы удалить рабочее пространство.

Виола!


1

Если у вас нет прав на сервере для удаления рабочих областей других людей, вы можете просто изменить имя определения сборки. TFS создаст новое рабочее пространство и отобразит его в «C: \ Build \ ProductReleases \ новое имя сборки здесь \ Sources».


1

Если применимо, вы также можете клонировать определение сборки и изменить ее имя. Это сработало для меня.


Спасибо за это. Сочетание удаления папки кэша и (повторного) клонирования моего определения сборки исправило это для меня.
HerbalMart

1

Я попробовал все следующие решения, такие как:

  1. Используйте кореш, чтобы удалить WS.
  2. Используйте команды tf для удаления рабочих областей удаленного сервера.
  3. Удалите папку кэша TFS.

У меня сработало следующее:

tf workspaces /remove:*

0

Я изменился

Build Definition -> Workspace -> Build Agent Folder

из

c:\some\path

в

$(SourceDir)

и это решило проблему.


0

При попытке «получить последнюю версию» проекта, который я ранее сопоставил с локальным каталогом, а затем удалил, я увидел то же самое сообщение об ошибке. Сначала я попробовал инструмент SideKick, а затем командную строку Visual Studio 2010, обе из которых сказали мне, что у меня нет сопоставленных рабочих областей.

Затем я искал «VersionControl.config» внутри c:/users/myuser/appdataи удалил 4 найденные ссылки. Я снова открыл Visual Studio, и мне удалось повторно сопоставить проект, больше никаких ошибок!


0

Самый простой способ сделать это - зайти в AppData и удалить кэш TFS (в зависимости от версии 3.0 или 4.0).

C: \ Users {Имя пользователя} \ AppData \ Local \ Microsoft \ Team Foundation \ 3.0 \ Cache или C: \ Users {UserName} \ AppData \ Local \ Microsoft \ Team Foundation \ 4.0 \ Cache


После очистки рабочих пространств с помощью вспомогательного инструмента VS и TFS этот ручной подход к удалению кэша сработал для меня. Спасибо!
espaciomore

0

Решение TDN сработало для меня, когда у меня возникла та же проблема. Сервер сборки создал рабочие области под моей учетной записью. Установка этого флажка позволила мне увидеть и удалить их.


0

Я получил ту же проблему в Visual Studio 2017 и TFS 2017. DefaultCollection должен быть сначала сопоставлен с вашим локальным путем. Каким-то образом этот шаг был пропущен, и я получил только сопоставленный MyFirstProject.

введите описание изображения здесь

Все, что вам нужно сделать, это:
1. Перейдите на веб-страницу TFS и удалите проект с сервера.

введите описание изображения здесь

- 2. Удалите проект из вашего локального "Worksapces"

введите описание изображения здесь

- 3. Перейдите в раздел «Управление подключениями», который обновит вашу домашнюю страницу в TeamExplorer.

введите описание изображения здесь

- 4. Вы получите страницу конфигурации, которая позволит вам настроить корневой путь к вашей коллекции DefaultCollection.

введите описание изображения здесь

- 5. Вы должны получить сообщение, что это было сделано успешно. Теперь вы можете создать свой проект.

введите описание изображения здесь

Важно сначала сопоставить корневой каталог вашей коллекции с рабочим пространством, а затем сопоставить новый проект.


0

Моя проблема была связана с использованием нескольких учетных записей. Вот так я смогла сменить аккаунт.

Откройте Team Explorer

Из большого выпадающего меню в верхней части панели ...

Перейдите к: Проекты и мои команды > Управление подключениями

Перейдите к: Управление подключениями > Подключиться к командному проекту

Используйте ссылку «Сменить пользователя» для переключения учетных записей.

Теперь имена рабочих пространств будут соответствовать выбранной учетной записи.


0

Я не мог заставить работать любое другое решение.

У меня была создана новая учетная запись, и у старой учетной записи больше не было разрешений (обе на одной машине).

Я попытался: 1) Удаление рабочей области (не мог видеть в VS с или без проверенных удаленных рабочих областей) 2) Удаление из командной строки 3) Команда нового владельца 4) Удаление кэша

Поэтому я просто открыл VS как администратор и сопоставил с другой папкой.


-1

У меня была эта проблема с автоматическими сборками Azure DevOps в локальном агенте сборки TFS. Удаление рабочей области с помощью TFS Sidekicks не сработало. И tf.exe даже не смог найти рабочее пространство для его удаления.

Это решение должно работать для TFS 2017, TFS 2018, DevOps Azure и, возможно, других версий:

  1. Обратите внимание на GUID рабочей области в сообщении об ошибке.
  2. На компьютере, на котором выполняется сборка, перейдите к:% USERPROFILE% \ AppData \ Local \ Microsoft \ Team Foundation \ (где% USERPROFILE% принадлежит пользователю, который запустил сборку).
  3. Найдите и удалите все экземпляры GUID рабочей области в этом каталоге. Вероятно, в каталоге «cache» будет папка, а также записи в папках «LocationServerMap.xml» и «LocalItemExclusion.config». Убери их всех.

Это сработало в моих обстоятельствах.


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.