Using multiple workspaces with Visual Studio
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!
The Manage Workspaces dialog
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.
- File menu –> Source Control submenu –> Advanced –> Workspaces…
- Launch the Source Control Explorer. On the toolbar, there is a “Workspace:” combo box. Open the combo box and select “Workspaces…”.
- (In Visual Studio 2012 and later.) Open the Pending Changes Page in the Team Explorer. From the Actions menu, select “Manage Workspaces.”
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.
Switching between 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.
Scenarios for using multiple workspaces
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:
|
|
| PHKELLEY-DEV_Main | $/Project/Main –> C:\Project\Main |
| PHKELLEY-DEV_Release1 | $/Project/Release1 –> C:\Project\Release1 |
| PHKELLEY-DEV_Release2 | $/Project/Release2 –> C:\Project\Release2 |
| PHKELLEY-DEV_Development | $/Project/Development –> C:\Project\Development |
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.
Performing integrations
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!).
Performance benefits
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.
Comments
Anonymous
May 15, 2015
Good article, but I have a suggestion for the issue with merging which is something I have been using myself for some time. I create a MERGE workspace which in your example would map to $/Project - this would then contain any/all branches. When I want to complete a merge, I make sure I have all changes from my Dev and Main workspaces checked in, I then open my merge workspace and Get Latest - I then complete my merges in this workspace and compile/test - once I'm happy it's all working I simply check it all back in and then switch to my respective Dev and Main workspaces and Get Latest which should now contain the merged files. The reason I started doing this was due to running into issues whereby I was required to merge changes while being in the middle of working on either the source or target branch. Because all merging is done locally, I found there was a risk of checking in some of the current unfinished work as part of the merge. Regards, WayneAnonymous
August 24, 2015
The comment has been removed