Team Foundation Server Source Control Explained

Tuesday Feb 8th 2011 by Jani Jarvinen

Source code management and version control are topics that can lead to heated discussions over the best solution. However one thing is clear: everyone needs version control. Even a developer working alone can benefit from a working solution. In this second part of the Microsoft ALM series, the focus is on Team Foundation Server's version control capabilities.


Microsoft entered the source code control business with Visual SourceSafe back in the 1990s, and even today, the product continues to be used by a large number of development shops. Still, many organizations have noticed SourceSafe to be problematic: database corruption is common. Since development companies live or die by their source code, one must be able to trust the software managing it.

When Microsoft chose to implement a replacement for Visual SourceSafe, the company had several goals in mind. These included speed, robustness and support for higher loads. This development lead to the version control system that is today part of Team Foundation Server (TFS).

The version control in TFS is aimed at professional development companies, but there is no practical limit to the number of users a TFS server installation can support. Thus, version control in TFS can be used by a one-man team or a large development organization with hundreds of developers.

The architecture of TFS is centralized. This means that all source code is maintained at a single location. In a centralized architecture the TFS server itself can be considered a single point of failure, but with high-availability solutions available in the Windows Server operating system, this does not need to be so. Similarly, the SQL Server database storing the actual source code bits can be mirrored on multiple servers.

This article will explore the source code control functionality in TFS 2010 (Figure 1). Although the focus is on the latest version, you can still benefit from this article should you be using for instance the 2008 version. Some of the details might not apply to version 2008, but the basics are still the same.

TFS version control is integrated into Microsoft Visual Studio and Expression Blend
Figure 1. Team Foundation Server version control is integrated into Microsoft Visual Studio and Expression Blend.

Download the Free ALM eBook

This article assumes you are familiar with the basic operations of TFS. If not, be sure to read the first part of this article series about Team Foundation Server and Microsoft's ALM solution.

Version Control Support in Team Foundation Server (TFS) 2010

Dependability and robustness are key ingredients to a professional version control system, and this is what TFS 2010 aims to deliver. In fact, version control can be considered core functionality in Team Foundation Server. Other features, such as team builds, are built to benefit from it.

TFS version control has been designed to integrate seamlessly with the latest versions of Microsoft Visual Studio. However, this does not mean that you could not use TFS version control with other software development products. It is also possible to use the version control fully manually through a command-line utility called tf or in a somewhat more limited fashion through the web access feature of TFS (Figure 2).

The TF command can be used to manipulate item in version control from the command-line
Figure 2. The TF command can be used to manipulate item in version control from the command-line.

  • The functionality in TFS can be divided into the following areas:
  • Basic functionality: checking files in and out
  • Locking: limiting concurrent edits
  • Branching and merging: work with different versions of the source code
  • Security: decide who can access the version control data and how.

The basic functionality in any version control system includes checking file in and out. To support concurrency, TFS allows multiple checkouts of the same file, but this can be disabled should the need arise. Items can also be exclusively locked so that nobody else can check in or out a file while it is locked. If concurrent checkouts are disabled in team project settings, then a lock is automatically placed on the file upon checkout.

Branching and merging can be considered advanced functions in TFS, but nonetheless, they are highly useful. The main idea of branching is to take a set of source code files and create a distinct version from those files. The branched code can live a life of its own separate from the original source files (Figure 3). For instance, if you are developing a generic application but need to make a specialized version for a certain customer, you could branch the customer customizations from the main source control tree (the "trunk"). Should the need arise later, you can again combine the customization code with the original source control line. This is called merging.

Branching and merging are useful functions in larger projects with continuous development
Figure 3. Branching and merging are useful functions in larger projects with continuous development.

Everything in TFS except Active Directory user rights version control are stored in a central SQL Server database. This includes team project settings, file data, changeset details, and so on. Because almost everything is in a central location, it is imperative to make sure you take regular backups of the SQL database(s) and have a disaster recovery plan. TFS backups can be taken with regular SQL Server backup tools, such as the built-in commands or with third-party products from names like Symantec or CA.

Version Control in Microsoft Visual Studio: The Three Windows

Working with TFS through Microsoft Visual Studio's integrated functions is a trouble-free job. To understand how version control is integrated into Microsoft Visual Studio, you need to be aware of three separate windows (or panes, depending on your point of view): the Source Control Explorer, Solution Explorer and Pending Changes windows.

If you haven't used version control in Microsoft Visual Studio before, the Source Control Explorer and Pending Changes windows might be new to you. The Solution Explorer window is without doubt a familiar one to every developer: with this window, you manage your projects and the files in them.

When you have connected to a Team Foundation Server instance, Solution Explorer will allow you to check out and check in files directly from the window by right-clicking the items. However, by default a check out occurs simply when you start editing a file in Visual Studio. For instance, if you open a C# source code file in the editor and start typing, the file is checked out. This is often the most convenient way to check out files.

Small icons shown by the Solution Explorer window help you distinguish between locked, checked out and added files, and so forth (Figure 4). A blue lock icon indicates that a file is part of source control but is not currently checked out. A red check mark indicates that the file has been checked out, and a yellow plus sign indicates that a file has been added to the project.

[Part 2, Figure 4 - Solution Explorer Icons.png]
Figure 4. Microsoft Visual Studio's Solution Explorer clearly shows locked, checked out and added files, for instance.

In TFS, a check out operation and the operation to get the latest version are separate from each other. In practice, this means that before checking out a file, you should execute a "Get Latest" command on the file(s) you wish to check out. This can be done by simply right-clicking an item in Solution Explorer, and choosing the Get Latest menu item. To change this default behavior, you can choose Microsoft Visual Studio's Tools/Options menu command, and navigate to the section Source Control/Visual Studio Team Foundation Server. From here, you can find an option named "Get latest version of item on check out" (Figure 5).

[Part 2, Figure 5 - Get Latest Version.png]
Figure 5. The Get Latest command can be automatically done when checking out an item.

Note that the design product Expression Blend also supports TFS version control in its latest incarnations, and does have its own built-in integration with TFS. Blend's Projects window (which is similar to Visual Studio's Solution Explorer window) allows checking in and out files, and also allows you to view version history as well.

In addition to the familiar windows in Blend and Microsoft Visual Studio, Visual Studio includes two additional but equally important windows. Let's see what features these windows have.

The Source Control Explorer and Pending Changes Windows

Although the Solution Explorer window in Visual Studio allows you to work with the files in a development project, to get a more holistic view of your version control tree, you will need the Source Control Explorer window (Figure 6). To open the window, choose the View/Other Windows/Source Control Explorer menu command, or double-click the Source Control node in Visual Studio's Team Explorer window.

[Figure 6Again.png]
Figure 6. The Source Control Explorer window allows you to browse files and see who is editing them.

The Source Control Explorer window allows you to view and manipulate files in your version control tree. You can do all the same operations through this window than you could do in Solution Explorer: for instance, you can check in and out files, rename them, delete them, and so on. The difference is that using the Source Control Explorer window, the files you work with do not need to be part of a Visual Studio development project, such as a C# project. For example, you could add an Excel spreadsheet to version control; this is something that you might not want to do through Solution Explorer.

Whenever you work with files under version control and edit, add or delete them, Visual Studio will not immediately commit the changes back to version control. Instead, this is done only when you check the changes in. In the mean time, all your changes are by default stored in a pending changes list, which can be seen through the Pending Changes window (Figure 7).

[Part 2, Figure 7 - Pending Changes.png]
Figure 7. By default, changes are collected to the Pending Changes window until they are checked in.

The Pending Changes window shows a list of files that have not been checked in. The window also indicates the operation (add, edit, delete or rename) requested. Usually, you do your check-ins through this window, since it allows you to conveniently check in multiple files in a single operation. You can also write a comment to accompany your checked in files, and you can link to a Team Foundation Server work item with the files.

Overall, one or more source files, optional comments and work item associations collectively form a changeset. A changeset in TFS is always checked in atomically, which means that the complete set either succeeds or fails in the check in. A changeset is associated with a unique ID, and can be later viewed for example through the Source Control Explorer window (Figure 8).

[Part 2, Figure 8 - Changeset.png]
Figure 8. A changeset is a collection of files, work items and comments.

In TFS version control, a changeset is an essential concept because it is the smallest set of changes that the system can process. A changeset can contain a single file, or a set of files. Furthermore, it is the basis of reporting, especially when used together with work items.

The Pending Changes window is also the gate to quality assurance within TFS. The administrator of the system can set up a set of policies, which can be enforced on the client. For example, a policy could say that all checked in code must first build successfully and pass a set of unit tests. This way, broken integration or incorrect versioning cannot break the source code in the version control tree. Note that with appropriate user rights, policies can be overridden. This is meant for temporary needs.

Best Practices for Working With TFS Version Control

Successfully using a version control system like TFS requires knowledge of the features available and also time-tested methods in using it. For instance branching and merging is an area which - if not done properly - can lead to lots of manual work. A similar thing occurs with concurrent edits and merge conflict resolution. These are common occurrences in a project, and the possible solutions need to be known by every member of the team. Unless the changes in a single file can be automatically merged by TFS, the developer must manually solve the conflict.

This article cannot be a complete guide for TFS version control best practices, but there is an excellent set of documentation available on both MSDN (Version Control) and on CodePlex. The links section at the end of this article points to these resources.

For instance, CodePlex contains a free guide called "Microsoft Visual Studio TFS Branching Guide 2010" that clearly walks through the good and bad ways of doing branches, and how projects should be organized to best support branching and merging. Similarly, the documentation on MSDN talks about concurrency issues in source code editing.

Both of these ebooks are recommended reading if you wish to take full advantage of the version control features in Team Foundation Server. The Microsoft Patterns & Practices book is also available on paper through Microsoft Press.


In this article, you learned the basic functionality of Team Foundation Server's version control and how it can be accessed from both Microsoft Visual Studio and Expression Blend 4. The integration with the development (and design) tools improves developer productivity and is a graphical way to work with the files in version control. Alternatively, you can use the command-line command tf to manage version control.

This article also showed what functions the Solution Explorer, Source Control Explorer and Pending Changes windows provide. For example, you learned how to check in and check out files from version control. You learned about the integrated experience and the important term of a changeset. A changeset is a collection of files and optional comments and associated work items that the version control processes as an atomic unit.

This article was the second part in the Microsoft ALM series about Team Foundation Server 2010. The first part introduced the overall picture of TFS, and is available here. The next part will focus on TFS work items.

See you next time!


Jani Jarvinen


MSDN product documentation, "Using Version Control"
Visual Studio TFS Branching Guide 2010
Microsoft Patterns & Practices guide "Team Development with Visual Studio Team Foundation Server"

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved