The past couple of posts I’ve made focus on workspaces and the differences between server and local workspaces. Visual Studio and TFS version control are designed to support the use of multiple workspaces on the same machine, but many customers use only one workspace. Depending on your situation, you might be missing out on a better user experience by limiting yourself to just one workspace!
Let’s look first at the Manage Workspaces dialog, which is used to look at all the workspaces on the current machine.
The Manage Workspaces dialog can be accessed through the following methods.
The Manage Workspaces dialog shows, by default, those workspaces on the local computer to which you have access. Most of the time that means that the workspaces belong to you. But if you’re on a shared machine and someone has created a public or public-limited workspace, then those workspaces will show up in this list as well.
You can check the “Show remote workspaces” checkbox at the bottom to refresh the list of workspaces and have it show instead all workspaces, on any machine, where you are the owner of the workspace.
From this dialog box, you can add new workspaces, delete existing workspaces, or edit workspaces you already have to change their properties. The properties which you can change are summarized in a previous blog post on workspaces.
You may recall that each workspace has its own set of working folders (also called mappings) and pending changes. The Source Control Explorer and Pending Changes Page in the Team Explorer each allow you to switch between workspaces so that you can see and manipulate the pending changes in each workspace. (In Visual Studio 2010 and earlier, the Pending Changes toolwindow also allows you to switch between workspaces.)
This screenshot shows the controls which allow you to select your workspace in the Source Control Explorer and in the Pending Changes Page of the Team Explorer. All the workspaces on the local machine to which you have access are available in either drop-down.
When you select a different workspace, you may notice that the Source Control Explorer’s left and right panes have some items change from grey to black, or black to grey. This is because the workspace you switched to may be mapping more items, fewer items, or an entirely different set of items with its working folders. The Local Path hyperlinks above the right pane may change accordingly as well.
In the Team Explorer’s Pending Changes Page, when you select a different workspace, the set of pending changes, your pending check-in comment, associated work items, etc. will all switch as well. Everything is preserved; you can toggle right back when you want to. Keep in mind, though, that a solution cannot span multiple workspaces and is always ‘in’ a particular workspace.
Many customers using TFS version control use branching and merging to control code movement and perform servicing on existing releases. For example, there might be a Main branch located at $/Project/Main, and several branches for different releases also located underneath $/Project, such as $/Project/Release1, $/Project/Release2. Often there is also a development branch called $/Project/Development.
Customers commonly create just one workspace on your machine that maps $/Project to a location on disk like C:\Project. In the example described above, that results in all four branches coming down to the local disk in the same folder. The engineer who does this might be working almost exclusively in the Development branch, and they end up having 4 times as much source code downloaded to their machine. If they end up having to make a change in the Release2 branch to fix a production issue, they will find their pending changes for Development ‘mixed in’ with their Release2 changes.
It’s much less error-prone to compartmentalize the branches by creating one workspace for every branch. In this particular scenario the customer might create four workspaces, instead:
This allows work to go on in each branch separately. If you are in the middle of a change in Development but are interrupted and have to make a change in Release2, then just close your copy of the solution from the Development branch and open your copy from the Release2 branch. This action will automatically switch the Pending Changes Page and Source Control Explorer’s workspaces to match the solution’s workspace. All your work from Development is still there and untouched; you can use the Release2 workspace to commit your change there, and then switch back to Development just as easily as you switched to Release2.
Some customers have mentioned that the reason they map all their branches in the same workspace is to perform integrations (merges) from branch to branch. You can still merge when using multiple workspaces described above. You always want to be performing the merge in the target branch – if I’m integrating from Development to Main, then the workspace selected should be PHKELLEY-DEV_Main, since that’s where changes are being pended and that’s the branch to be modified with a check-in. The source branch doesn’t have to be mapped in the same workspace (or mapped at all!).
If you’re using local workspaces, then you can see some performance benefits by switching to using “one branch == one workspace”. Local workspaces are intended for customers with small to medium size projects where the workspace has 50,000 or fewer items. I have seen customers where each branch of their source code is well within our scalability target for local workspaces – but the customer has placed several branches of source code all in the same workspace. The total number of items then ends up being far beyond 50,000, and performance suffers or “TF400030: The local data store is currently in use by another operation” errors are observed. Simply separating out the branches with a “one branch, one workspace” philosophy brings them back within the scalability target and they end up being much happier.