Developer Product Briefs

Better Version Control With TFVC

Team Foundation Version Control (TFVC) offers more granular security, better centralization, robust auditing and reporting, and more.

• By Jeff Levinson
• 07/01/2006

Better Version Control With TFVC
Team Foundation Version Control offers more granular security, better centralization, robust auditing and reporting, and more.
by Jeff Levinson

June 28, 2006

Microsoft developers have never really had it easy in the area of enterprise-class version control systems. Let's face it: Visual Source Safe (VSS) is not the answer to problems faced by large development teams. So we were forced to turn to other solutions, which didn't integrate well with Visual Studio or were incredibly complicated to learn. Team Foundation Version Control (TFVC) fixes that problem.

TFVC uses SQL Server 2005 as the back-end data store, which is a far cry from VSS's file-system structure. Because SQL Server 2005 sits on the back end, retrieving and storing data is faster, more reliable, and far more scalable. In addition, Team Foundation Server provides a secure system. With VSS you could only control read or read/write access to the source files; in TFVC, you can get more granular and control security down to the file level (see Table 1).

A huge benefit of using TFVC comes from the communications structure—everything is done over HTTP through standards-based Web services. This means that Microsoft developers can now work on geographically distributed teams and access the central repository over the Internet. To help accommodate the potentially vast distances, Microsoft created a TFVC Proxy Server that handles syncing files in the background and allowing developers access to the latest code from a close-in location.

I've been asked numerous times why someone should implement TFVC; a few key benefits make it worth the cost. Many large companies that develop with Visual Studio can have anywhere from a few to several hundred separate development teams. This in itself is not a cause for concern—that each team has its own VSS installation is.

This means that every team has installed VSS in a separate location (usually a file share) and that the location isn't necessarily secure. Plus, each team administers its own repositories. So the first reason to implement TFVC is centralization. A single instance of TFVC with adequate hardware can support approximately 550 active developers and terabytes of data. It resides in a central location and can be administered by a single person. The location can (should) be a secured location such as a datacenter.

The second major benefit is rolled up into one word: security. As I mentioned, this includes security at the file level, but it also includes robust auditing and reporting capabilities. These capabilities prove to be a timesaver, with the Sarbanes-Oxley Act (SOX) requiring ever more auditing down to the source code level.

The final benefit is client platform neutrality. Many version control systems that have been developed for the Java community have been made to work with Visual Studio (although, not very well), such as CVS, Subversion, ClearCase, and so on. The Team System team, with its decision to use HTTP and Web services as the communication medium, has provided the ability for TFVC to integrate well into other development environments. As of this writing, many open source and closed source projects and applications integrate with Team Foundation Server (see "Resources for VSTS and TFS" for more information). This means that regardless of the platform, you still have a common, easy-to-use, enterprise-class version control repository.

A Picture Is Worth...
Now that you know why you would use TFVC, it's time to see what you get. The interface is a deceptively simple file explorer type of view (see Figure 1). This allows you to navigate multiple Team Projects and multiple solutions within those projects. The real power of TFVC comes from the options you'll find within this view.

For example, double-clicking on a file displays detailed information about not only the file, but also the changeset associated with it (see Figure 2). A changeset is the sum total of the changes made during a given check-in. This means that a changeset includes not only files that were changed (added, edited, deleted), but also all the work items associated with the changeset.

(If you're unfamiliar with work items, they can be described as the glue that makes the development methodology "work." They are items such as tasks, bugs, requirements, and so on. Using TFVC, you can associate items checked into the repository with a specific task, which makes project management a whole lot simpler.)

Labels work differently in TFVC from the way they work in VSS. In VSS you could label files so you knew what versions of files went with a given release or build. Have you ever tried to automate VSS for these tasks? You almost need a separate development team to do it. TFVC allows you to set labels for arbitrary files and retrieve those files at a later date (see Figure 3).

Branching, merging, and shelving take center stage in TFVC. As with VSS, you can branch files and then merge those files (see Figure 4). You can compare files in different branches or plug in your own differencing tools such as Beyond Compare. These features make it easier to allow for multiple check-outs (although that isn't always the best idea).

Shelving is a new and useful concept. Take this situation: You're working on a new change to some code, and the project won't build. You don't want to (or can't) check it in, but you want someone else to review it or you want it stored temporarily in TFVC. In this case, you would create a Shelveset. This checks in the changes and allows other people to view and edit the files, but does not add the files to a changeset or version the files so they are "outside" the normal build path. A useful tool indeed!

Team Foundation Server and Team Foundation Version Control offer so many features that the benefits of using these tools far outweigh the cost of setting them up. And once you have this infrastructure in place, you will realize even more benefits from the additional tools included with Team Foundation Server (see the article, "Using Development Methodologies With TFS," for more information). Check it out by downloading the 180-day trial from Microsoft.

About the Author
Jeff Levinson is a solution design and integration architect at a Fortune 500 company. He is a Microsoft Architect MVP and holds the MCAD, MCSD, MCDBA, SCJP, and Security+ certificates. He is a coauthor of the new book, Pro Visual Studio 2005 Team System.