Welcome to MSDN Blogs Sign in | Join | Help

How to handle "The path X is already mapped in workspace Y"

This has come up before on the forums, but I don't think I've ever posted about it here.  Today I saw a reference to the TFS Workspace Gotcha! post in today's Team System Rocks VSTS Links roundup.  There's a command to deal with the problem, but it's not obvious.

Here's the post.

I have been working with a team that has recently migrated a TFS source project from a trail TFS to a full production server (different server).  They disconnected their solution from source control (removes all the SCC stuff from .sln) files and then tried to add to the new TFS.

However, they were getting weird errors.

I suggested that they might not have their workspace mapped correctly to the new TFS project.

When they tried to map the workspace, they got the following error:

The Path <local path> is already mapped in workspace <machine name [old tfs server]>

Hmm, I thought we removed all the source stuff?

Turns out that the workspace mappings are stored in a file called:

VersionControl.config under the users local settings/application data directory.

I could find no way (other than manually editing the forementioned file) to remove the workspace mapping from that local folder to the other TFS server (which is no longer in usage).

Anyway, once that was done, all was good in the world.

Thanks go out to Kevin Jones for his excellent post on Workspaces in TFS.

While deleting versioncontrol.config will clear the cache, we've actually got a way to do it from the command line.  The command "tf workspaces /remove:*" clears out all of the cached workspaces (it only affects the cache file).  You can also specify "/s:http://oldserver:8080" to clear out only the workspaces that were on the old server. The MSDN documentation for the workspaces command is at http://msdn2.microsoft.com/en-us/library/54dkh0y3.aspx.

The reason that he hit this is due to switching servers. Every server has a unique identifier, which is a GUID. Each local path can only be mapped in a single workspace, and the versioncontrol.config cache file is the file that the client uses to determine what server to use when given a local path (e.g., tf edit c:\projects\BigApp\foo.cs).

He originally had a workspace on the old server that used the local path he wanted to use with the new server. Let's say that's c:\projects. When he tried to create the new workspace on the new server (GUID2) that he also wanted to map to c:\projects, the client saw that the old server (GUID1) was already using that local path. Since the IDs for the servers did not match, the client complained that c:\projects is already mapped to the old workspace on the old server.

The client uses the server's ID as the real name of a server.  The reason is that the name could change, either because an admin changed the server's name or because a user needs to access the server through a different name depending on the connection (intranet vs. internet).  The only "name" guaranteed not to change is the ID.  So, when presented with a different network name, the client requests the ID from the server and compares it to the IDs listed in the versioncontrol.config cache file.  If the ID matches one of them, the client simply updates the existing entry to have the new name, so that subsequent uses of the new name do not incur an extra request to check the ID.  If the ID does not match any of them, then the server is different than any of the servers in the cache file.

The error message looks like it's showing the machine, but it's actually showing the workspace name.  The reason for the confusion there is that the version control integration in VS creates a default workspace that has the same name as the machine.

The problem will not occur if you upgrade the same server (i.e., you don't create a new server), as an upgraded server still has the same ID.

Though /remove isn't mentioned (part 2 does mention the error message at the end), you can check out Mickey Gousset's workspace articles for more information on workspaces and managing them.

tags: , ,

Published Tuesday, September 12, 2006 10:15 AM by buckh

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Workspace Mapping 出現問題 ?

過去幾個月,零零星星的聽見到 某些正在使用 TFS 與 TE 的團隊 提到,  Workspace Mapping 好像怪怪的,常常會有問題 明明對應好了,好像會跑掉 東西放不完整... 這個 抱怨就進階的...
Tuesday, September 12, 2006 8:13 PM by Refines.Info["Polo Lee"]

# VSTS Links - 09/13/2006

Andy Johns on Bye Bye TFS.

Rob Caron on Team Foundation Server Language Change Package.

Aaron Hallberg...
Wednesday, September 13, 2006 8:50 AM by Team System News

# An introduction, 1350 posts later

On the Microsoft forums , that is...no, I didn't suddenly eclipse Raymond . As you probably haven't noticed,

Tuesday, October 17, 2006 3:23 AM by BUGBUG: poor title

# re: How to handle "The path X is already mapped in workspace Y"

But this doesn't help when trying to remove the temporary workspaces TFS creates during the build. I have a temporary workspace that has been left "hanging" and can't get rid of it.

Wednesday, May 27, 2009 12:10 PM by pb

# re: How to handle "The path X is already mapped in workspace Y"

pb, you'll want to run tf workspaces /owner:<whatever your build service account is> /computer:* to get a list of the workspaces.  You can then delete it with tf workspace /delete:workspaceName;workspaceOnwer.

Buck

Wednesday, May 27, 2009 1:12 PM by buckh

# re: How to handle "The path X is already mapped in workspace Y"

Hi

I am getting this error also, but I'm not sure it is for the same reason.

Our projects share our core frame work solutions.

So DevPathA will have a build configured and reference Source Control for main solutions and frame work solutions, DevPathB will have build configured and reference source control for it's branch of solutions and the same framework solutions.

When we run build on DevBathB, we receive the error.

Basically, 2 builds on 2 different branches of source, referencing the same set of shared sources.

Any ideas?

Thanks,

David

Thursday, June 11, 2009 6:32 AM by David Quinlan

# re: How to handle "The path X is already mapped in workspace Y"

David, that should be fine, but you will need to make sure that the local paths for the workspace mappings in each of the build definitions do not overlap. They can both map the same thing from version control, but they cannot use the same local path (i.e., they each need their own independent local copy).

If you've had to rename or re-arrange builds, it could be that you need to delete the old build workspaces to make way for the new ones.  You can use the tf workspace /delete command.  The form would be tf workspace /delete workspaceName;workspaceOwner /s:http://yourserver:8080, which an admin could do.  Or you could log in as the build service account and delete the workspace(s) with the tf workspace /delete command without needing to be admin.

Buck

Thursday, June 11, 2009 9:13 AM by buckh

# re: How to handle "The path X is already mapped in workspace Y"

Cheers Buck,

What about having 2 builds for the same branch, one that deploys to a DEV server on a daily basis, the other, that deploys to a TEST server on demand (or weekly).

David

Thursday, June 11, 2009 9:57 AM by David Quinlan

# re: How to handle "The path X is already mapped in workspace Y"

David, that should work very well.  We do this internally, for example, where we have CI and nightly builds for the same branch.

As long as you keep the local paths in the workspace mappings disjoint, you should be good.

Buck

Thursday, June 11, 2009 10:50 AM by buckh

# re: How to handle "The path X is already mapped in workspace Y"

I have removed all references in Version.config for both VS 2005 and VS 2008 and I have deleted the workspace using fs workspace command utility. Yet I still have the problem. They changed our domain name and the old domain is in the "workspace" but I cannot seem to find out where to delete it.

Tuesday, June 23, 2009 8:42 AM by Anton de Gruchy

# re: How to handle "The path X is already mapped in workspace Y"

Anton, did you clone a server?  If so, that can cause issues.  Changing the domain name won't confuse the client.

http://blogs.msdn.com/buckh/archive/2006/10/17/creating-a-new-server-from-an-old-one-beware-of-the-instanceid.aspx

Buck

Wednesday, July 08, 2009 9:05 PM by buckh

# re: How to handle "The path X is already mapped in workspace Y"

Running "tf workspaces /remove:*" from VS command prompt helped me fix the error.

I also had to reboot the VS IDE and removed the old workspace and created a new one and everything started working.

Thank you !

Monday, July 13, 2009 10:33 AM by Srikanth

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker