Adding Source Code to Team Foundation Server

There are countless ways that you can lay out your code in Team Foundation Server and it is beyond the scope of this article to give detailed reasons why you might use one over another. The approach chosen below is just an example and useful for the purposes of demonstration. Specifically I have chosen to add three sub folders, Trunk, Branches and Releases.

When folders are added to the version control system they are not instantly visible to other developers, they must be checked in like files. In this case before checking in I am going to add a set of solution and project files to the repository and check it in all at once.

In addition to performance and scalability enhancements the fact that TFS houses its version control system on SQL Server 2005 means that it is possible to use an atomic commit or check-in approach, that is, either the entire check-in succeeds, or it all fails. Check-ins can be performed either from Source Control Explorer or from Solution Explorer (or from the Pending Changes tool window).

One of the places where the version control system integrates with the work item store is at check-in. When checking in it is possible to associate that check-in with one or more work items. For example, since this is the initial import of the code I could navigate to the Work Items view in the Check In dialog and select Work Item 3387 and associate it. Beware however the default selection when associating work items is to set the Check-in Action to "Resolve", which in the case of tasks closes the work item -- hence the usefulness of the Recycle Bin query created earlier.

Once a check-in has been completed it is called a Changeset and a source code repository is nothing more than a series of Changesets piled on top of each other over time. Since a Changeset is a distinct entity in the database it is possible to relate data to it and so the relationship between the Changeset created above and work item 3387 can be navigated from the Changeset itself or the Work Item. The screenshot below shows the Changeset linked from the Work Item.

New Concept: Shelvesets

One of the new concepts related to version control in Team Foundation Server is the introduction of Shelvesets, temporary sets of files stored within SQL Server but which aren't actually part of the code base (yet). The idea with Shelvesets is that a developer can take some changes that they have made during the day and put it somewhere safe when they go away for the weekend. Creating a Shelveset is pretty straight forward. First the developer selects “Shelve Pending Changes” from the context menu in Solution Explorer, they are then presented with the following dialog.

The developer gives the Shelveset a name so that they can find it and restore it later and like the check-in dialog it is possible to add comments and associate work items. Shelvesets only contain the files modified since the Changeset version that was pulled down from the version control store so they are relatively cheap to create.

In order to restore the Shelveset, the "Unshelve Pending Changes" context menu option should be selected and the developer is given the opportunity to search or shelve sets created by them or other developers.

The fact that a Shelveset can be shared around means that they are quite good for performing code reviews and enforcing a single check-in point policy which can be useful around ship time for a particular project.

In the next part of this article I will go beyond shelvesets and look at the full-blown branching support in TFS, show how TFS supports automated build processes and take a look at what the reporting facility has to offer.