Tags: addition, computer, folder, folders, message, microsoft, msdn, software, studio, visual, working, workspace, workspaces

Working folder already in use by another workspace on this computer

On Microsoft » Microsoft Visual Studio

5,987 words with 5 Comments; publish: Wed, 19 Dec 2007 21:53:00 GMT; (300140.63, « »)

I am getting this message on a computer on which there are no other workspaces for that computer. In addition, all of the working folders have been deleted for the workspace that I am working in. We do occasionally log into that box with another user name, but there were no workspaces defined under that login either. (Besides, can't we see all the known workspaces if you log into TFS as admin anyway? -- BTW: I don't particularly like that "feature" under the standard workspace editing location for admins because its easy to grab the wrong one.)

All Comments

Leave a comment...

  • 5 Comments
    • You may want to try running "tf workspaces /server:[server] /computer:[computername] /owner:* /format:detailed" to see if any of the workspaces which reside on that machine have a working folder mapping that conflicts. Note that if one workspace maps "C:\Documents and Settings", no other workspace can map any sub folder thereof.

      Edit: Forgot to mention- if you've used more than one server on that machine, you may also have a conflict between those workspace mappings. A given folder on your local machine may only be mapped in one workspace on one server at any time.

      Hope this helps!

      Cheers,

      Adam

      #1; Sun, 09 Sep 2007 13:12:00 GMT
    • Yes, we are able to see the conflicting working folders on the same box through the user of the workspaces command. The problem is that there is no API to delete them.

      No workspace in the cache matches * for server [servername]

      After all of that the workspaces command (tf workspaces /s:[servername] /computer:[computer name] /owner:* /format:detailed) still returns the list of projects and workspace mappings that are clearly the source of conflict for us.

      #2; Sun, 09 Sep 2007 13:13:00 GMT
    • "tf workspaces /remove" only removes the entry from the local cache file- the workspaces still exists on the server. This is used mostly for cleaning up workspaces which pointed at servers that no longer exist or have been restored to an earlier backup version.

      If the workspace is owned by another user, you need to use "tf workspace /delete [workspacename];[domain]\[username] /server:[servername]" to delete the workspace. Note that you must have the "Administer Workspaces" permission to perform this operation if you are not the workspace owner.

      Hope this helps!

      Cheers,

      Adam

      #3; Sun, 09 Sep 2007 13:14:00 GMT
    • Thank you very much Adam for your quick and helpful response. I was missing the

      ;[domain]\[user name] portion of the workspace /delete command.

      I get a nice clean result from the tf workspaces command now. It would have helped if the help docs for the command would have been more explicit about specifying domain\username like your forum response was. Also the return for doing it wrong was certainly not giving us clues. Finally, how come delete project doesn't clean up these tables appropriately?
      #4; Sun, 09 Sep 2007 13:15:00 GMT
    • I'll follow up internally to see what we can do to make the messaging more clear.

      Regarding delete project- I'm guessing you mean the TfsDeleteProject.exe tool? It doesn't actually delete any workspaces since a workspace may be mapped to multiple Team Projects. All it does related to version control is to delete the entire team project folder. This data can still be restored via the "undelete" command, though you will have to provide the "/newname" option to relocate it an existing team project.

      Thank you for your feedback!

      Cheers,

      Adam

      #5; Sun, 09 Sep 2007 13:16:00 GMT