Workspaces in Team Foundation Server - Part 1

Workspaces are one of the magical elements in TFS that can sneak up and bite you when you least expect it. One of the reasons they can do this is because they are somewhat out of sight, out of mind and can be created without any intervention of the user.

First a primer on what they are and how they work. A workspace represents a user (Larry) working on a specific computer (Workstation1) with a selection of files from Team Foundation Version Control (TFVC), maybe it is all of the files stored in the “BigApplication” project ($BigApplication), that are copied to my workstation in a specific location, perhaps to D:\DevelopmentProjects\BigApplication. This data represents four distinct pieces of information; who, what workstation, which server files/directories, where are the server files mapped to on the workstation.

All of this information is stored on the Team Foundation Server.

When a user first connects to TFVC and gets files from the server to their workstation the user is asked where to copy the files on the workstation. This creates the “which” and “where” elements of the four pieces of information, by simply connecting to TFS the user and workstation (“who” and “what”) are identified to the server. Once the user has told TFS where to copy the files TFS automatically creates a workspace with the relevant information. Using the example above I would have a workspace with the following information:

Who: Larry
What Workstation: Workstation1
Which Server Files: $BigApplication
Where on the workstation: D:\DevelopmentProjects\BigApplication

You can also think of the “which” and the “where” as a single piece of information that is a mapping from the server to the workstation.

This is all fine and good as long as you stay working within the constraints of this workspace. Challenges can be encountered in numerous ways, I will describe two scenarios next that can cause confusion and then I will look into how you manage workspaces effectively.

Involving other Developers

With large complex distributed applications coupled with complex development environments security rights and permissions can often be a challenge to resolve and debug. There may be cases where a developer is unable to connect to all aspects of the TFS environment or when executing code under development that runs against distributed web services and/or remote databases errors may be encountered that may or may not be security related. When attempting to resolve security related concerns logging onto the same workstation as a different user is a common tactic.

So now Anne, my team architect with increased permissions, comes to help me resolve my problems. She logs onto my machine to run the application under his credentials. She fires up Visual Studio, connects to TFS and performs a “get” on the latest version of the code and says that she want to store the code in D:\DevelopmentProjects\BigApplication. This results in an error from Visual Studio because TFS knows that I have already mapped source code from the server to that location on my workstation.



TFS will not permit another user to overwrite the files that I may have already copied to the workstation. In this new scenario the workspace contains the following data:

Who: Anne
What Workstation: Workstation1
Which Server Files: $BigApplication
Where on the workstation: D:\DevelopmentProjects\BigApplication

Because this conflicts with the workspace that I had already created TFS will not permit it. This same error will be encountered if I get a new workstation and my old workstation is given to a new developer. Even if the workstation is formatted if the workstation name remains the same and the new owner tries to copy source files from TFS to the location D:\ DevelopmentProjects\BigApplication it will fail because of the conflict with the previous workspace which is stored on the server.

Where did those files come from?

After working on the Big Application for a while I am asked to help out with an urgent bug fix on another project that has a looming deadline. I still have a few files checked out from my work on Big Application, but that’s okay as I will only be working on Important Application for a day or two. I connect to TFVC and get the source code for “Important Application”. When TFS asks me for the location to download the code I provide the path D:\DevelopmentProjects\ImportantApplication.

I then make a few changes fixing the bug and proceed to checkin my code. I am surprised to see that the checkin window is listing all of the files that I have checked out from Important Application as well as the files I have checked out from Big Application even though I don’t have the Big Application solution open in Visual Studio.

This all comes back to workspaces. The Pending Changes window displays all pending changes (check outs) that I have for the workspace I am working in. When I performed the “get” for Important Application TFS added the source mapping to the same workspace. My workspace definition now has the following data:

Who: Larry
What Workstation: Workstation1
Which Server Files: $BigApplication
Where on the workstation: D:\DevelopmentProjects\BigApplication
Which Server Files: $ImportantApplication
Where on the workstation: D:\DevelopmentProjects\ImportantApplication

Managing Workspaces

Workspaces can be managed from Visual Studio by opening the Source Control Explorer and selecting the dropdown list of workspaces.



By selecting the dropdown list you will see the list of all workspaces on the TFS for the current user, enabling you to choose which workspace you want to set as your current workspace context. The last entry in the list is “Workspaces…” by selecting this list value you will open the “Manage Workspaces” window. This window displays the same list of workspaces as the selection list presented but rather than using this to set the active workspace you use this selection to manage the selected workspace. Additional information available from this window is which workstation the workspace is associated with along with any comment that may have been provided with the workspace.

If you have never worked directly with workspaces and have let TFS create and manage them for you then you will most likely only see one workspace for each workstation (Computer) that you have used to connect to TFS. The default name that TFS uses for workspaces is the name of the workstation. In the screenshot above you see 3 workspaces that were each created from the same workstation (TFSRTM08). The default workspace that TFS created is also named TFSRTM08 (the second one in the list). Selecting the TFSRTM08 workspace and selecting edit takes us to a screen like this:



You can see in the top section where the workspace information for who (Darren), what workstation (TFSRTM08 [Computer]) as well as on which server this workspace is tracked (TFSRTM08 [Server]). The center section for the comment is just an arbitrary text field that can help remind you of what the workspace is for (I added “Default workspace” in this example). The bottom section has the mapping from which server files to where they go on the local workstation. This workstation is mapping the contents of the “$/BuildProject/Main/WindowsFormsApplication1” location on the server to the workstation location of “C:\MSLabs\VSTS 2008\Work\Team Build\WindowsFormsApplication1” as well as the contents of the “$/BuildProject/TeamBuildTypes” to the workstation location of “C:\MSLabs\VSTS 2008\Work\Team Build\TeamBuildTypes”.

As you can see the mapping is not keeping the relative locations from the server layout equal to the relative locations on the workstation. There is no requirement to do so. However if you happen to create any sort of relative relationships from the contents of one directory to the contents of the other, perhaps for external file based assembly references or other file references this relationship may not match how other users create their workspaces. Use caution!

There is also no reason that you need to restrict your workspaces to a single TFS project. You can map folders from any project to almost any workstation location you care to all within a single workspace. The reason I say almost is because you are not permitted to create a mapping that would cause a workstation collision in which two different server projects would end up mapping different files to the same workstation location. In other words you can’t do this:



Attempting to do so will generate this error:


You are not permitted to map two different source directories to the same workstation directory as this would cause a collision.

Another interesting thing that you can do with workspaces is cloak a location. In the sample below the “$/eBanking1/TFRobotUnitTestSampleSolution/TFRobotTest” server location is cloaked.


As you can see the “$/eBanking1/TFRobotUnitTestSampleSolution/TFRobotTest” location is a sub folder of the “$/eBanking1/TFRobotUnitTestSampleSolution” location. By setting the status to “Cloaked” the contents of the “$/eBanking1/TFRobotUnitTestSampleSolution/TFRobotTest” folder are not downloaded when performing a “get” from the server. This can be particularly handy when you need to work with a subset of the information contained in source control and the other information can be of significant size. The catch is forgetting the you have the location cloaked and experiencing frustration when trying to figure out why some of the files don’t download for you!

In my next post on this subject I will look at managing workspaces from the command line as well as some recommended best practices.