Team Foundation Server – Trying to understand Server versus Local Workspaces

I often have these mind numbing episodes where I am trying to understand technology, pondering over the “why” and trying to create a mental “picture”. For some time I have had a background thread running on workspaces and have decided to create a summary of my understanding to initiative some collaboration that will lead us to the oracle of workspaces. Make sure you read Brian’s blog https://blogs.msdn.com/b/bharry/archive/2011/08/02/version-control-model-enhancements-in-tfs-11.aspx and Matt’s video as mentioned in the post first.

Topics herein:

• Team Foundation Server 2010 Workspace
• Team Foundation Server 11 Workspace
• When should you use which workspace?

Team Foundation Server 2010 Workspace

With Team Foundation Server 2005, 2008 and 2010 (as shown below), we had the ability to create server (private|public|public limited) workspaces, which in essence map the version control folder and content on the server to a local file storage, for a specific user on a specific workstation.

In the following illustration we are showing that the $/Explore2010 folder is mapped to the  c:\temp\1 folder. Once you perform a get latest, you will have a replica of the version control as known by the server in the mapped file storage location.

Any gets, check-out or check-ins are performed against the server and tracked in the server workspace as part of the change deltas. This assumes that we have server (left) to client (right) connectivity and introduces an entire chapter of confusion and gremlins when users are working and making changes when offline. The core issue is, that the changes are forced on the client in an offline scenario, after which the server thinks that the worlds are out of sync.

Team Foundation Server 11 Workspaces

With Team Foundation Server 11 we still have the server workspaces, but are welcoming the local workspace. When we compare server and local workspaces we note the following:

1. A local workspace includes a $TF folder and files, which is not in the version control.
2. A server workspace does not include the $TF folder and files.
3. The attributes of files within the workspace differ. With server workspaces the files are read-only if not checked out, whereas with local workspaces the files are modifiable.

The change deltas are stored on the client, as part of the local workspace and using the internal $TF folder, which enables us to work offline with a much slicker and smoother experience. Local operations include edit/checkout, add, rename, delete, undo, and diff, which are ideal for local workspaces as they do not require any server connectivity. Everything else typically forces the user to connect with and collaborate with the server.

The only “watch out” we have found so far is that the automatic detection of renames are not yet supported when working with the local workspace.

NOTE: Watch the space … there are plans to make the rename experience better for Beta

For example, if we rename Test.txt.txt on our local workspace, the change appears as an Add, not as a Rename in our workspace.

In terms of Team Foundation Server, the rename is translated to an add and a delete as shown below:

When should you use which workspace?

if ( ( you are expecting large number of files > 100,000 )
|| ( you want a locking workflow ) )
     consider Server Workspace
else consider Local Workspace

Comments

• Anonymous
  June 14, 2012
  This is an awesome new feature for TFS2012!!! One question I have, however: Is there (or will there be) an update/vsix for VS2010sp1 that can use this feature? Something like a Team Explorer 2012 for VS2010?

• Anonymous
  June 14, 2012
  @John, the message from the kitchen is that the feature is only available with VS 2012 and TFS 2012.  There are no plans to “back port” the client side work to enable 2010 clients to use the feature. If you feel that the feature is needed on VS2010, you should  raise the idea on visualstudio.uservoice.com.

• Anonymous
  July 24, 2012
  So if i understand correctly, i can do a check-in to a "private" repository, (just like git commit)? and when i am done, i can then check-in my code into the "shared" repository (just like git push)?

• Anonymous
  November 06, 2013
  I just found out today that you can change all new workspaces to be Server by clicking on Team, Team Project Collection Settings...,  Source Control, workspace settings.  While Local workspaces are OK but we have a very large set of files.  So changing the default is really going to help.

• Anonymous
  July 07, 2016
  Hi, i know this is kind of old but we are still using TFS 2010. We are currently using Server type workspaces and we want to change it to Local type. If I simple change the default option under "Team Project Collection Settings" will that impact already created workspaces? or will it simple set the change for new workspaces only? I need to understand how the change affects already created workspsaces