Question

So I’ve got a situation where we have a project with 10 developers. Each developer, when they come in for the day, is randomly issued a machine to use for development that day. The machine names are different, say DEV01 – DEV10. At the time that they are issued to the developers, the machines are identical, and no changes the developers make during the day are persisted on the machines (source code changes are stored in TFS, not locally). These are of course actually virtual machines, but that’s not really relevant to the point at hand.

The problem is that each morning, the developers run into 3 issues:

1) The machine that they are assigned may not be the same machine they were last assigned to. For example, DevMan A might have used DEV04 yesterday, and received DEV06 today. His workspace definitions are now tied to DEV06; he must create a new workspace, or migrate the old workspace to DEV04.

2) The machine that they are assigned may have been in use yesterday, and some of the mappings may conflict. For example, DevMan A might have DEV04 today, and wish to create a workspace mapping the project folder to “C:\MyProj\Solution”. However, DevMan B had DEV04 yesterday, and he used the same project folder. TFS now complains.

3) This may be the first time they are on a given machine. They now need to recreate for this machine all of their source-control mappings for the new machine.

All of these issues can be resolved in a straightforward fashion on a case-by-case basis, but it does sap some productivity from the morning. We’d much prefer if the TFS workspace definitions could be ‘relaxed’, such that they did not include the machine name in the definition somehow. Barring that, if anyone is aware of a solution to the above problems that can run automatically, or with limited user intervention, that would also be ideal.

Answer 1

First, the super-obvious answer is to dedicate machines to users.

Secondly… if you really want to solve the problem as stated:

You cannot use workspaces without assigning them to a specific machine. This assumption is implicit in the product. But you can fool it 🙂
Warning: This recipe seems to work but I have not personally run a project using it.

1. Assign a “Virtual” machine name for each user, i.e UseridVM
2. For each virtual machine the following (persistent or startup scripted) setup is needed:
   • create a new environment variable “User Variable” i.e _CLUSTER_NETWORK_NAME_=UseridVM
3. Nice to have: Use a virtual hard drive which is dedicated to the user id and mapped (or mounted using a script) to “D:” which follows the user from VM to VM.

Now, when the user opens up Visual Studio, the workspace will use the specified value “UseridVM” as the machine name, thus the same workspace will be found on each machine.

If you don’t have a persistent virtual hard drive, then each user must be sure to do a ‘real’ “Get Latest” (Get Specific Version, check all boxes) when starting for the day because the workspace memorizes what files have already been downloaded and will not re-download them if it feels they already exist.