Inside VSTS

New Features in TFS 2008

Jeff walks you through the best of what's new in Team Foundation Server 2008, starting with the many helpful additions to Version Control.

• By Jeff Levinson
• 11/11/2007

Team System 2005, while a very stable system, was a version 1 release. Team System 2008 adds more stability, more scalability and more (and better) tool integration. It also incorporates a lot of requests from developers. The items covered in this column fall into the tool integration and developer requests categories.

Annotate
After the initial 2005 release, Microsoft released a set of Power Tools for TFS which included the Annotate feature. This allowed you to view a version of a file and see all the changes that have been made to it so far. It also noted who made the change and what changeset it was a part of.

When you installed the TFS Power Tools, this option was added to the IDE menu or could be run from the command line, but it was relatively unknown. To use this option, right-click a file in Source Control Explorer (or the History window) and select Annotate.

As you can see in Figure 1, John created the file as part of changeset 14. Steve then made some changes, and Lori made even more changes. You can get additional details on the changeset by clicking the changeset number on the left. In addition, you can drill down and annotate each version of the file -- very handy for figuring out who broke what and when!

Folder Diffs
In TFS 2005, you could compare files for differences, but not the contents of folders. TFS 2008 adds the ability to perform a folder diff. This makes it very easy to see changes between different branches or labels at the file level.

Figure 2 shows that a comparison was done between two different server paths to view the differences between the Production and Development branches of the HelloWorld project. You can also perform a folder diff by comparing a server path to a local path or two local paths.

Get Latest on Checkout
Finally, due to popular demand, TFS 2008 allows you to set a "Get Latest on Checkout" option, which retrieves the latest version of a file when you start editing it.

In 2005, when you started editing (or did a Check Out For Edit), it checked out the version you currently had on your local machine. For example, if there was a file called foo.cs that had four versions and you checked in version 3, that was the version on your local machine. If another developer made changes to that version and checked it in, then there was a version 4 in TFS.

Now, if you started editing version 3, TFS would check out version 3. When you checked the file in, you'd get a conflict that you had to resolve. In Visual SourceSafe, when you started editing version 3, it would automatically get version 4 and that's what you would be editing.

The Team System team has now added this feature to TFS 2008 (you have to set this feature; it isn't on by default). But is this a good thing, and should you use it?

The short answer is no. Here's the problem: Let's say that Developer A makes changes to three files called A.cs, B.cs and C.cs and checks those files in. Now, say Developer B makes changes to B.cs, C.cs and adds a new file called D.cs. When Developer A next goes to edit B.cs, TFS is going to perform a Get Latest and Checkout of just that file.

The problem is obvious: Developer B checked in files B, C and D together as a single changeset and presumably made changes in such a way that these three files have dependencies on one another. If Developer B is only editing the new version of B.cs, then the code will never compile correctly and -- even worse -- Developer A may change B.cs to make it build!

In general, my advice is to not use this feature but to get into the habit of performing a Get Latest before you start working with code, and certainly before you do a check in.