email article printer friendly

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.