Erreur de génération en équipe: le chemin & # 8230; est déjà associé à l'espace de travail

Question

Lors de la création d'une nouvelle génération dans Team Foundation Server, le message d'erreur suivant s'affiche lors de la tentative d'exécution de la nouvelle.

  

Le chemin   C: \ Build \ ProductReleases \ FullBuildv5.4.2x \ Sources   est déjà associé à l'espace de travail   BuildServer_23.

Je ne parviens pas à voir un espace de travail portant ce nom dans la boîte de dialogue correspondante.

Answer 1

Utilisez l'utilitaire de ligne de commande TF - Outil de contrôle de version de Team Foundation ( tf ).

Vous pouvez obtenir la liste de tous les espaces de travail en créant une invite de commande Visual Studio , en passant dans votre dossier d'espace de travail et en émettant les commandes suivantes:

C:\YourWorkspaceFolder>tf workspaces /owner:*

Vous devriez voir votre espace de travail problématique dans la liste ainsi que son propriétaire.

Vous pouvez supprimer l'espace de travail à l'aide de la commande suivante:

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

Answer 2

Supprimez simplement le contenu du (des) dossier (s) suivant (s):

C: \ Utilisateurs \ Nom d'utilisateur \ AppData \ Local \ Microsoft \ Team Foundation \ 3.0 \ Cache

Où UserName est l'utilisateur actuel ou actuel et 3.0 le numéro de version.

Answer 3

J'ai reçu cette erreur, causée par deux définitions de construction pointant vers la même source. Le problème était que j'ai utilisé un répertoire de construction statique dans l'agent de compilation.

Ce message de forum décrit exactement mon problème et ma résolution: http: // social. msdn.microsoft.com/Forums/en-US/tfsbuild/thread/60a4138a-9b28-4c46-bdf4-f9775ce43c3e/

Answer 4

Nous avons eu le même problème, mais la suppression de l'espace de travail du serveur TFS ne fonctionnait pas. (Je devrais mentionner que j'ai attrapé la VM de mes collègues qui était déjà configurée avec ses informations d'identification.)

Pour moi, cela a fonctionné: http: //blogs.msdn. com / b / buckh / archive / 2006/09/12 / chemin-est-déjà-mappé-dans-workspace.aspx

Je viens d'entrer dans: ... \ Paramètres locaux \ Application Data \ j'ai fait une recherche sur VersionControl.config, ouvert le dossier contenant ce fichier et supprimé tout son contenu.

Auparavant, j’avais essayé d’éditer manuellement le fichier, mais le même message d’erreur s’était poursuivi.

J'espère que cela vous aidera.

Answer 5

J'avais un problème similaire et pour supprimer l'espace de travail qui me causait un problème, je me suis connecté à un autre ordinateur avec le client TFS installé et j'ai exécuté les opérations suivantes:

• Dans le menu Fichier , pointez sur Contrôle de la source , Options avancées , puis cliquez sur Espaces de travail ... .
• Dans la boîte de dialogue Gérer les espaces de travail , cochez la case Afficher les packages distants .
• Dans la colonne Nom , sélectionnez l'espace de travail à supprimer, puis cliquez sur Supprimer .
• dans Dans la boîte de dialogue Confirmation , cliquez sur OK .

Answer 6

Pour une raison quelconque, je ne parvenais pas à supprimer l'espace de travail de l'utilitaire de ligne de commande. Heureusement, j'ai trouvé Team Foundation Sidekicks 2010 (from cet article ) qui est gratuit et fournit une interface graphique pour afficher et supprimer des espaces de travail TFS et de nombreuses autres fonctionnalités utiles de TFS.

Answer 7

J'ai eu un problème similaire lorsque Visual Studio 2010 s'est plaint d'un espace de travail déjà mappé, mais au lieu de supprimer l'intégralité de l'espace de travail, j'ai utilisé les éléments suivants à partir de l'invite de commandes Visual Studio: "espace de travail tf PROBLEM_WORKSPACE_NAME". Cela a amené un " Edit Workspace " dialogue. À partir de là, j'ai pu supprimer le chemin en question du dossier de travail "Dossiers de travail". liste, qui s'est débarrassé de l'erreur.

Answer 8

Voici ce que j'ai fait (bien ce que je fais):

À l'aide de TFS Sidekicks, supprimez les filtres utilisateur et serveur afin qu'ils soient vides. Cela vous permettra d’obtenir tous les espaces de travail.

Vérifiez l'erreur de construction pour le nom de l'espace de travail. Dans le cas des PO, il s'agit de BuildServer_23. C’est différent dans mon environnement, mais en gros, il suffit de faire correspondre le nom de l’erreur avec celui de la liste de sidekick de tfs.

Cliquez sur le x rouge pour supprimer l'espace de travail.

Viola!

Answer 9

le reste était assez facile.

Allez simplement dans ce dossier: C: \ Utilisateurs {Nom d'utilisateur} \ AppData \ Local \ Microsoft \ Team Foundation \ 4 \ Cache et supprimez tout ce qui se trouve dans le dossier.

Answer 10

Je recevais une exception me disant que le fichier était déjà mappé dans un autre espace de travail: "Le chemin d'accès {Chemin du fichier} est déjà mappé dans l'espace de travail {Nom de l'espace de travail}."

Cet espace de travail a été supprimé avant . Avec l'aide d'un de mes amis, j'ai découvert que TFS sauvegardait les informations de l'espace de travail sous le répertoire des paramètres locaux de l'utilisateur. Nous avons trouvé un fichier nommé:

VersionControl.config sous {Répertoire Documents et paramètres utilisateur} \ Paramètres locaux \ Application Data \ Microsoft \ Team Foundation \ 1.0 \ Cache. Ce fichier contient tout le mappage local de TFS. Probablement lorsque vous utilisez la méthode Map sans utiliser: public void DeleteMapping (mappage de WorkingFolder); avant de supprimer l'espace de travail, les informations de mappage ne sont pas supprimées de ce fichier utilisé par TFS pour vérifier si vous avez déjà mappé un chemin spécifique.

Pour résoudre ce problème, supprimez toutes les clés du fichier de configuration. Ne supprimez pas le fichier car vous le récupérerez du cache du serveur.

Answer 11

Si vous ne disposez pas des autorisations nécessaires sur le serveur pour supprimer les espaces de travail d'autres personnes, vous pouvez simplement modifier le nom de la définition de construction. TFS créera un nouvel espace de travail et le mappera sur "C: \ Build \ ProductReleases \ nouveau nom de génération ici \ Sources".

Answer 12

Le cas échéant, vous pouvez également cloner la définition de construction et changer son nom. Cela a fonctionné pour moi.

Answer 13

J'ai essayé toutes les solutions suivantes, telles que:

1. Utilisez des sidekicks pour supprimer WS.
2. Utilisez les commandes tf pour supprimer les espaces de travail du serveur distant.
3. Supprimez le dossier de cache TFS.

Ce qui suit a fonctionné pour moi:

tf workspaces /remove:*

Answer 14

j'ai changé

Build Definition -> Workspace -> Build Agent Folder

de

c:\some\path

à

$(SourceDir)

et le problème a été résolu.

Answer 15

En essayant de "Obtenir la dernière version" d'un projet que j'avais précédemment mappé sur un répertoire local puis supprimé, j'ai vu le même message d'erreur. J’ai d’abord essayé l’outil SideKick, puis l’invite de commande Visual Studio 2010, qui m’avaient tous deux indiqué que je ne mappais aucun espace de travail.

Ensuite, j'ai cherché 'VersionControl.config' dans c: / users / myuser / appdata et supprimé les 4 références qu'il a trouvées. J'ai rouvert Visual Studio et j'ai pu remapper le projet, plus d'erreur!

Answer 16

Pour ce faire, le moyen le plus simple consiste à accéder à votre AppData et à supprimer le cache TFS (selon la version 3.0 ou 4.0)

C: \ Utilisateurs {Nom d'utilisateur} \ AppData \ Local \ Microsoft \ Team Foundation \ 3.0 \ Cache ou C: \ Utilisateurs {Nom d'utilisateur} \ AppData \ Local \ Microsoft \ Team Foundation \ 4.0 \ Cache

Answer 17

La solution de TDN a fonctionné pour moi alors que je rencontrais le même problème. Le serveur de génération a créé des espaces de travail sous mon compte. Cochez cette case m'a permis de les voir et de les supprimer.

Answer 18

J'ai le même problème dans Visual Studio 2017 et TFS 2017. DefaultCollection doit d'abord être mappé sur votre chemin local. En quelque sorte, cette étape a été ignorée et seul MyFirstProject a été mappé.

Il vous suffit de:
- 1. Accédez à votre page Web TFS et supprimez le projet du serveur.

- 2. supprimer le projet de votre espace de travail local "

"

- 3. Accédez à "Gérer les connexions". qui actualisera votre page d'accueil dans TeamExplorer.

- 4. Vous obtiendrez une page de configuration qui vous permettra de configurer le chemin racine de votre collection par défaut.

- 5. Vous devriez recevoir un message indiquant que l'opération a été effectuée avec succès. Vous pouvez maintenant créer votre projet.

Il est important de mapper d'abord la racine de votre collection sur votre espace de travail, puis de mapper un nouveau projet.

Answer 19

Mon problème était lié à l'utilisation de plusieurs comptes. C’est ainsi que j’ai pu changer de compte.

Ouvrez Team Explorer

Dans le grand menu déroulant situé en haut du volet ...

Accédez à: Projets et mes équipes > Gestion des connexions

Accédez à: Gérer les connexions > Se connecter à un projet d'équipe

Utilisez le " Changer d'utilisateur " lien pour changer de compte.

Les noms de l'espace de travail correspondront au compte choisi.

Answer 20

Supprimez simplement l'espace de travail:

workspace /delete "the-workspace-name"

Answer 21

J'ai eu ce problème avec cela avec les générations automatisées Azure DevOps dans un agent de génération TFS sur site. La suppression de l'espace de travail à l'aide de TFS Sidekicks ne fonctionnait pas. Et tf.exe n'a même pas pu trouver l'espace de travail pour le supprimer.

Cette solution devrait fonctionner pour TFS 2017, TFS 2018, Azure DevOps et éventuellement d'autres versions:

1. Notez le GUID de l'espace de travail dans le message d'erreur.
2. Sur la machine sur laquelle la construction est en cours, accédez à:% USERPROFILE% \ AppData \ Local \ Microsoft \ Team Foundation \ (où% USERPROFILE% appartient à l'utilisateur qui a déclenché la construction).
3. Recherchez et supprimez toutes les instances du GUID de l'espace de travail dans ce répertoire. Il y aura probablement un dossier dans un répertoire 'cache', ainsi que des entrées dans 'LocationServerMap.xml' et 'LocalItemExclusions.config'. Supprimez-les tous.

Cela a fonctionné dans mon cas.