We are working with some developers from India.  We have been forced to share some of our machines with the off shore developers while we figure out our distant relationship and connectivity issues when working on applications that have many end points within our network.  So the remote team will remote into certain desktops.  And yes we have enough licenses for the software.

Recently we have started to work with TFS source control.  We moved away from Source Safe and CVS.  Well TFS has the concept of workspaces.  Workspaces map locations in the TFS source control to local folders.  As a user you may log into multiple machines and create workspaces on those machines.  If you look at the works spaces on a machine via the Workspaces drop down in Visual Studio you will see all the workspaces that you have created across the multiple machines. 

So now say another user logs into your machine on the evening shift.  Why not safe a machine? Maybe not the best idea maybe so, but who cares.  Because this scenario can be just as valid if I decide to run-as another user in my Visual Studio environment to debug a security context specific bug.  Well if I need to get the latest code from TFS I will have to create a workspace and map to the same local file system as the workspace created under my everyday Windows account.  Well TFS will not allow this.  Two workspaces cannot be mapped to the same local path.

You will have to delete the other workspace so you can map a new workspace for the currently logged in user.  I guess you could say that why are you mapping to the same place.  Why not isolate the code from each developer in there own profiles?  Yes we could, but up to this point we have just wanted consistency in directory structure origin.  I tried this it just moved our problem to the IIS Virtual directory mappings.  Yep, we are using IIS rather than the built in web server, reality first I say. 

So assuming we are not going to change our ways, we will have to find the workspace that is using our local mapping and delete it.  To do this we need to use the tf.exe command line tool. 

 

Here is the work around I have come up with while sharing a machine between users: (substituted users and machine names)

The bolded characters are my command line text.

First list the workspaces for a machine, in this case it is JoesComputer for all owners.  Notice the /owner:* wildcard search.

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE>tf workspaces /computer:JoesComputer /owner:* /server:http://TFSServer:8080

Server: TFSServer

Workspace               Owner                Computer     Comment

----------------------- -------------------- ------------ -----------------------------------------------------------------------

HOBO_MyAccount          ShookJ               JoesComputer Temporary CruiseControl.NET Workspace

HOBO_NotificationServer ShookJ               JoesComputer Temporary CruiseControl.NET Workspace

HOBO_OnlineBillPayCsr   ShookJ               JoesComputer Temporary CruiseControl.NET Workspace

HOBO_ProfileManager     ShookJ               JoesComputer Temporary CruiseControl.NET Workspace

JoesComputer            ccnetServiceAccount  JoesComputer

JoesComputer            BullPenUser             JoesComputer

Then delete each of the Workspaces that are on the machine mapped to you machine name. 

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE>tf workspace /delete JoesComputer;ServDevelopmentBuild /server:http://TFSServer:8080

A deleted workspace cannot be recovered.

Workspace 'JoesComputer;ServDevelopmentBuild' on server 'http://TFSServer:8080' has 0 pending change(s).

Are you sure you want to delete the workspace? (Yes/No) y

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE>tf workspace /delete JoesComputer;BullPenUser /server:http://TFSServer:8080

A deleted workspace cannot be recovered.

Workspace 'JoesComputer;BullPenUser' on server 'http://TFSServer:8080' has 3 pending change(s).

Are you sure you want to delete the workspace? (Yes/No) y

This worked for me because we happened to have a workspace name that was the same as the machine name.  Technically that is not the reason for the conflict mentioned in the email below.  No two workspaces mapped to the same computer can point to the same folder.  Great.  But we cannot share workspaces either across user profiles.  Seems pretty crummy. 

There Is a more advanced search that will show you the mappings also so you know which workspaces to delete.

tf workspaces /computer:JoesComputer /owner:* /server:http://TFSServer:8080 /format:detailed

Then just manually recreate your workspace.  We will just have to live with this while sharing machines.

Has anyone our their created a script to make this more streamline?  Because I have admin rights on TFS this may not work for all users.  I will have to drill down on this.  But another path would be to isolate by user profile and thus have your own workspace.  Then create a script that will re-map your IIS virtual directories.  I have wanted to work with PowerShell and maybe this would be a good piece of automation to get me started.

BTW  I have also faced issues with the new VSTS DB Pro tool in a shared workstation environment.  The temporary validation database is only owned by the person that created it.  But when another developer logs onto a colleagues machine and opens a solution with a database project in it you may receive errors.  If you try to build the project you will receive errors.  I found that the temporary database from the primary user is trying to be accessed by the visiting user.  The database file is secured to a single owner.  More on this later.