Issues with Team Foundation Server Workspaces

We often receive support requests where the core issue lies with the TFS workspace. So I’d like to clarify some things about this topic.

Workspace basics

A workspace is basically storing the links between folders in the Team Foundation Server repository and the corresponding local folders on your computer’s hard disk. It keeps track of the local version and the remote version and the state of those files.

Server Workspace vs. Local Workspace

A workspace can be either located on the server or on the local computer. With a Server Workspace, the state of the workspace is managed on the server. So you need to have a connection to TFS when performing any SCC related operation.

In a Local Workspace many source code control operations are performed locally. That enables you to work offline for most of the time, but you cannot use some of the TFS features then. Most importantly, it is not possible to enforce exclusive checkouts.

The TFS-MSSCCI-Provider only works with Server Workspaces. So, as far as Ivercy is concerned, you can't use a Local Workspace anyway.

The TFS documentation explains the differences between Local and Server Workspaces in more detail.

Mapping of Working Folders

A core purpose of a Workspace is to map a repository folder to a local file system folder. Each distinct repository folder can be mapped to a local folder only once within one workspace. If you try to add two different mappings for the same repository folder in the Team Explorer “Manage Workspaces” dialog, you will receive an error message.

A mapping of a folder will usually be inherited by its subfolders and the sub-hierarchy from TFS will be mapped to an identical hierarchy in the file system.

Now, in contrast to the situation above, there will not be an error message, if you add an explicit mapping for a repository folder that inherited a different mapping from its parent folder. It is obvious that only one mapping can work if the inherited mapping is in conflict to the explicit mapping. Other than what you might expect, it is not the explicit mapping taking precedence over the inherited mapping, but it is whichever was created first wins. The other local working folder will be ignored and files will not be synced to the local folder without an error message.

The issues with TFS Workspaces and Microsoft Access

This sub-header here deliberately references Microsoft Access and not Ivercy, as the Microsoft SCC-Plug-In is likewise affected by these issues.

When creating an Access project from TFS with either Ivercy or the MS-SCC-PlugIn you select a local working folder for this project to be created in. So you would expect these two folders to be mapped to each other in the TFS workspace. – Unfortunately, this is not exactly true.

Ivercy will create the yourProjectName_IvercyTmp subfolder and this subfolder will be mapped to the selected repository folder. The MS-SCC-PlugIn does exactly the same with its projectName.scc subfolder. The subfolder will contain all the source files. Only the working copy of the Access database itself, which is not directly version-controlled, will be put in the parent folder - the one you actually selected. The parent folder is not mapped to the TFS repository by Ivercy (or the MS-SCC-PlugIn) at all.

So there is a mismatch between the folder hierarchy in TFS and on folder hierarchy your local disk. This in itself is not a problem at all.

However, this fact may easily become a problem. As both of the SCC-Add-Ins secretly swap the folder you selected for their own sub-working-folder, you are set up to make mistakes when configuring working folder mappings in other tools.

If you use another tool, like Team Explorer, to work with some other part of your project, you might select a folder on a higher level in the repository to be mapped to your local disk. This will then include the subfolder where your Access project resides. On the lowest level, were your Access source files are stored, these mappings do not match.

Now the problem from the Workspace basics section above kicks in. The working folder used by Ivercy might not be synced with the repository anymore. Most SCC operations will fail then.

The design choice of using an additional subfolder for Ivercy’s working copy of the source files may create some confusion, but it is actually the lesser of two evils.

Guidelines to avoid trouble

There is a fairly simple solution to avoid the issues described above.

Use a dedicated TFS workspace for working with Ivercy!

Adhere to the constraints listed here when dealing with this dedicated workspace.

Do not use this workspace with other tools (e.g. the MS-SCC-Plugin).
Use this workspace with Team Explorer only if you are explicitly working on files from the managed Access databases (e.g. for restoring a deleted file).
Never manually add or change folder mappings within that workspace in Team Explorer.

You can delete folder mappings manually, if you are going to create a new working copy in another local folder.
You can safely use the same workspace for multiple different Ivercy/Access projects.

If you stick to these guidelines, you should not have any trouble with workspaces and the folder mapping concept.

We prepared a step by step walkthrough on how to use a dedicated workspace when creating a local copy of your database from the TFS repository.