TFS Source Control 2012–Workspaces Part 1

Source Control is one of the oldest parts of Team Foundation Server and probably the most used one as well. Every version of Source Control introduced some new functionality.

A short historical overview of the key adjustments

• TFS 2005 brought the first version. SQL Server based version control as a successor of SourceSafe
• TFS 2008 brought some small enhancements.
• TFS 2010 brought first class branches and visualizing your branching strategy and introduced the concept of public workspaces
• TFS 2012 introduces local workspaces

Explaining the variations

Since TFS 2012 contains all the stuff from previous versions as well, let me explain an important concept with this 2012 version.

Workspaces, Local or Server

Workspaces is a concept that is present since the first version of TFS but is not widely known by all TFS users. I can imagine why. The workspace has always been a little bit hidden in the interface. To go to your workspace, open Source Control Explorer en click the workspaces dropdown.

If you click the [Workspaces…] a dialog appears in which you can create, edit and delete workspaces.

But why do you need that?

Workspaces are a very powerful concept which you can use to isolate your changes. A workspace is a mapping between what is on the server and what should be on your client.

The picture above shows that a local folder C:\ProjectA is populated from the TFS folder $\ProjectA\Main. The mapping that this is the case is stored in a workspace. A workspace has some other properties as well that make this unique ( like username, computername and workspacename).

You can also map folders from different Team Projects into 1 local folder. This is used when you for example have shared libraries that you want to use inside a project. (more about this you can find in my previous post about Generic Libraries).

A TFS folder can be mapped in unlimited workspaces. A local folder can only be used in 1 workspace at a time.

When you make connection to TFS for the first time, a workspace with your computername is automatically created for you. Every solution you check in, all files that you add, regardless of the teamproject will be added as a mapping to this workspace. This makes things a little confusing when you work at several projects at the same time.

Pending changes that you see are always shown per workspace, not per project or solution or Team Project. You can imagine that this might mess things up when you check in all changes but the changes are for several projects.

My advice is to create 1 workspace per Team Project. When you start a project, start by creating a workspace and point this to the project you are working on.

Local or Server 

TFS 2012 introduces Local workspaces. If you migrate from TFS 2010 or TFS 2008, all projects have Server Workspaces. The default setting for new Team Projects in TFS 2012 is “Local Workspace”

Local workspaces have one great benefit. Files are not read-only anymore. You can use any type of editor you like and TFS will pick up the changes automatically. If you add files, edit files or delete files, all is shown in your pending changes window!

Server workspaces require a connection to the server. You need to check-out the file before you can edit it. By checking out, TFS removes the read-only flag and you can work on it.

There are some more differences. MSDN has a great article about what to choose when: http://msdn.microsoft.com/en-us/library/tfs/bb892960

The most important things:

• Local workspace allow you to work offline easily
• Local workspace can not have check out locks on files. You cannot claim a file exclusively
• Migrated Team Projects have Server Workspaces
• The default workspace type is configurable at Team Project Collection Level
• Workspace types can be mixes. Some users have local some users have server workspaces

In my next post I will talk a bit more about workspaces

TFS Source Control 2012–Workspaces Part 2