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:projectsBigAppfoo.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: tfs, team foundation server, version control