Accessing the Work Item Store

Having created a Team Project one of the first things that a team must do is knock down the set of initial work items that are created. These work items help teams go through the initial set of activities required to get a project successfully off the ground and vary depending on what process template was selected. By expanding the Team Project node the Work Items folder becomes visible, and drilling down further reveals a set of canned queries that can be used to enumerate all or some of the work items.

Writing Custom Work Item Queries

Eventually it will be necessary to write a new work item query. Queries can be placed in one of two folders, “Team Queries” and “My Queries”. Team Queries is a globally accessible container by all developers in the Team Project and My Queries is a private set of queries that each developer has to themselves.

One of the queries that I commonly find useful that doesn't come with the out of the box process templates is a Recycle Bin query. The Recycle Bin query allows me to look at work items that have been recently closed for the purpose of re-opening them (accidental closure of work items does happen). The first step is selecting “Add Query” from the Work Items node context menu.

Once the query editor is displayed the simple user interface can be used to filter down the list of work items required based on some simple expressions. In the case above, the query is configured to return all work items in the current Team Project where the State equals closed.

Using Team Foundation Version Control

Having accessed work items it's time to start using the version control system included in Team Foundation Server. Like most of the other features in TFS the version control store sits on top of SQL Server 2005 which provides a high degree of performance and scalability (in fact the version control store at Microsoft which is hosted on top of TFS has an estimated size of one terabyte).

The first version control-related work item that development teams will come across is the migration of existing source code. The work item provides a high level overview of what needs to be done when migrating source code.

Configuring a Workspace

Before a developer can add files to the version control store they need to map the logical structure of the version control store to the file system on their local machine. Team Foundation Server introduces the concept of Workspaces. A Workspace is a set of mappings between physical locations and the file system which is aligned to a particular user and computer combination. As a developer works on files they are logically checked out into the Workspace. To set up a Workspace the developer needs to double click on the Source Control icon under the Team Project in Team Explorer and go to the Workspace dropdown menu.

I find it is easiest to map the root of the entire source tree ($/ like Visual SourceSafe) to a specific location on the local drive and have that as the only mapping. My own personal approach is to have a “Sandboxes” on the root directory of my data drive and under that have a sub directory with the name of the TFS server that I am connecting to (I connect to multiple TFS servers so this is a necessity to avoid confusion).

Once the mappings have been established, navigating the Source Control Explorer will list out what the local path is for that logical location in the source tree. At this point you are ready to start adding source code to the repository.

One limitation that is placed on developers is that they cannot add files to the root of the version control store ($/) and all of the first level folders are directly related to a particular Team Project. The logic behind this is that one Team Foundation Server installation is the home for a great number of projects and each project should work within their own area.