Team Foundation Server – Trying to understand Server versus Local Workspaces

  • Article

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.

Workspace_1

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.Workspace_3

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.

Workspace_2

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.

Workspace_4

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 Smile

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.

Workspace_5

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

Workspace_6

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