I’ve written a bit already about working with Team Foundation Server (TFS) 2010 and have been thinking about a few other topics so I decided to wrap them all into one big post.  I’ve been working with TFS for around nine months now.  My first experiences with TFS were largely negative but as I’ve worked with it I’ve found that much of that negativity was due to a bias against the check-out model for version control and a lack of understanding of what else TFS could do for me and my team.  Over these nine months I’ve come to really appreciate its capabilities and have found ways to work around some of its shortcomings.

The ideas here come straight from my day-to-day experiences working with TFS.  Everything I’m including is something I’ve found that has made me more productive.  I’m by no means a TFS expert and reading this post certainly won’t make you one either but I strongly believe that it will help you work more effectively.

In this post we’ll look at three main areas:

• Tools
• Version Control
• Project Management

I assume at least a basic working knowledge of version control and project management concepts.  As such, I don’t spend much, if any, time discussing basic concepts like performing check ins, defining changesets, or what MS Project does.

I hope you find the tips contained within to be useful and worthy of inclusion into your workflow.

Tools

One of the first thing I noticed when I started with TFS is that its basic tool support is pretty weak.  Many of the tools that ship with TFS are rudimentary at best and other features such as shell integration are just missing.  In this section we’ll examine some workarounds and ways to be more productive.

TFS Power Tools

The TFS Power Tools are essential utilities to simplify many day-to-day tasks and circumvent other shortcomings.  I firmly believe that the first thing (ok, second to installing Visual Studio) any developer working with TFS version control on a regular basis needs to do is install the TFS Power Tools.

Installing the Power Tools

1. Open the Extension Manager from the Tools menu in Visual Studio 2010.
2. Click the Online Gallery Tab
3. Locate the Team Foundation Server Power Tools extension
   Depending upon the extension’s popularity it may or may not be listed on the featured on the front page of the online gallery so you may need to search for it
4. Select the power tools and click the download button.
5. When prompted Run or Save the installer package
   If there are any instances of Visual Studio running the installer will stop until they are closed.  The installer detects previous versions of Visual Studio too so you’ll need to close those as well
6. Select either a typical or custom installation
   The typical option should be sufficient for most users but anyone wanting to use the PowerShell Cmdlets will want to select custom install.  The tools I use most frequently are the command line interface, the Visual Studio integration, and the Windows Shell Extension
7. Click through the remaining pages in the wizard to complete the installation
   A reboot may be necessary to activate the shell extensions

Shell Integration

One of the biggest benefits of using TFS is that it integrates version control and project management capabilities into the Visual Studio IDE.  For developers already spending the majority of their day in Visual Studio this is usually a good thing since Visual Studio manages a lot of the action behind the scenes.  Unfortunately this benefit can also be one of its biggest drawbacks.

TFS uses a check out model for managing versioned files.  Visual Studio performs a silent, implicit check out on any files being edited within the IDE but what happens when we need to edit versioned files outside of Visual Studio?

Aside from a command line utility TFS doesn’t offer any way to manage versioned files outside of Visual Studio!  Unless we’re intimately familiar with the command line utility we’re forced to jump back to VS, go to Source Control Explorer, locate the file(s), and check them out before returning to the other program.  This is the first place that the power tools come to the rescue.

Although the shell integration isn’t as full-featured as what we get with something like Tortoise SVN I still find it sufficient for most tasks.  Depending on what I’m doing I’ll often use it before going to Source Control Explorer for simple tasks.

The shell integration is intended for routine operations like getting the latest version, checking in and out, adding, and comparing files.  There are no options for branching, merging, alerts, or annotating.  A huge miss in the power tools is that there’s no option for history either.

Power Tools Command Line Utility

Command line junkies will appreciate the fact that the power tools also come with a command line utility.  Much of the functionality provided by the power tools is only available through tfpt.exe.  We’ll discuss several of the commands available to us through the command line utility in detail later.  Full documentation of the commands available through tfpt.exe is available through the /? switch.

TFS Command Line Utility

TFS itself ships with a command line utility named tf.exe.  I really don’t find myself using tf.exe all that frequently mostly because of the shell integration supplied with the power tools.  The only command I find myself using with any regularity is tf get.

Basic documentation about tf.exe can be found by running it with the /? switch.  Full documentation is available on MSDN and is easily accessed by running tf msdn.

Changing the Compare and Merge Tools

Any version control system needs tools for comparing files and resolving conflicts and TFS is no exception.  Like many of the tools that ship with TFS the compare/merge tools are pretty simplistic and lack many of the features found in other tools in the same niche.  If you’re used to products such as WinMerge this can be a nuisance but TFS allows us to not only configure which tool we’d like to use for these tasks but to define them by action and file extension.

Note: What follows below are the basic steps for changing the compare and merge tools.  Check your desired tool’s documentation for specific configuration information.

Custom tool configuration is rather straight forward:

1. Open the options dialog in Visual Studio (Tools –> Options)
2. Expand the Source Control node
3. Select the Visual Studio Team Foundation Server node
4. Click the “Configure User Tools…” button

The Configure User Tools dialog is pretty simple.  In addition to allowing adding new tool configurations the dialog lists any configured tools and allows their modification or removal.  The Configure Tool accessed through the Add or Modify buttons is where the real configuration happens.

Extension: The file extension associated with the tool
To indicate that the tool applies to all extensions use .*

Operation: Merge or Compare

Command: The full path of the tool’s executable

Arguments: Any applicable command line arguments
Use the arrow button to select tokens for files or labels.

Version Control

As developers most of our interactions with TFS will be with its version control system.  Given that TFS is intended to be managed within Visual Studio the integration with Visual Studio is pretty solid.  I find that most of the version control related headaches are actually due to the check-out model employed by TFS rather than TFS itself.  That being said, version control in TFS isn’t particularly great and if you’re only using TFS for version control you may consider alternative versioning systems because better dedicated solutions are available.

In this section we’ll examine some of the ways to help keep the check-out model out of the way and decreasing productivity.

Keeping Your Workspace Tidy

When working on projects it’s really easy to neglect basic housekeeping.  Over time workspaces can get really messy and some spring cleaning will be necessary to restore some order.  At first glance cleaning a workspace can seem daunting but TFS Power Tools can make it trivial.

Unchanged Files

One big drawback of check-out model that I’ve previously discussed is that every change, even temporary ones, require files to be checked out.  How many times have do we edit a file to toss in some form of debugging helper just to remove it a few minutes later?  Under the check-out model all of these files are checked out but unchanged.  Visual Studio itself can compound the problem by checking out some files related to projects and solutions but never changing them.

When it’s time to check in the changes all of these unchanged files will be included in the pending changes list.  If any unchanged files are included in the check in TFS will detect that they are unchanged and won’t include them in the changeset.  This behavior is OK but if you’re like me you’ll want to review your changes before actually checking them in just to be sure you’re not about to do something stupid like checking in a forgotten debugger; statement in a JavaScript file (not that I’ve ever done that…) One or two unchanged files aren’t too bad to deal with but sifting through more than that is just a waste of time.  Wouldn’t it be nice to undo the check out on the unchanged files before reviewing them for check in?

Without the power tools the only way I know to undo the check out on the unchanged files is to manually compare the files one at a time and undo if there are no changes.  The power tools provide a really handy alternative in the form of the tfpt uu command.

tfpt uu is a command line utility that will undo the check out on all of the unchanged files in a workspace at the same time.  The default behavior will update the workspace and look for unchanged files before prompting to undo them but that behavior can be controlled though some command line switches.  The most useful switches are /recursive that checks filespecs with full recursion and /noget that bypasses getting latest on the workspace before comparing the files.  Full documentation for tfpt uu can be found using the /? switch.

The tfpt uu command has become part of my workflow.  I almost always use it just before a check in and will often run it just to help keep my workspace tidy.  If only there were a similar command for my desk.

Removing Unversioned Files

It is not uncommon for unversioned files to creep into our workspace.  These unversioned files could come from any number of sources: compiled binaries, log files, files we intended to add but changed our mind, etc…  The TFS Power Tools offer an easy way to clean up these files through the tfpt treeclean command.

tfpt treeclean will scan the workspace for all files and folders not under version control and remove them.  A /preview option is available to show which files will be affected without deleting anything.

Getting Latest on Check Out

One thing we noticed with TFS is that it doesn’t automatically get the latest version of a file when it is checked out.  More often than not we’d go to check in a change only to have TFS step in and inform us about changes in the repository that needed to be resolved.  We’d then need to get latest on those files to merge the changes and resolve any conflicts before TFS would allow us to check it in.

We found that in many instances there would be multiple check ins for a file between the last time we got latest and when we checked it out.  This meant that before we even got started making any changes we were already going to have problems trying to check in the file.  So why doesn’t TFS automatically get the latest version upon checkout?

Doug Neumann from the TFS team at Microsoft explained the rationale in a forum post:

It turns out that this is by design, so let me explain the reasoning behind it.  When you perform a get operation to populate your workspace with a set of files, you are setting yourself up with a consistent snapshot from source control.  Typically, the configuration of source on your system represents a point in time snapshot of files from the repository that are known to work together, and therefore is buildable and testable.

As a developer working in a workspace, you are isolated from the changes being made by other developers.  You control when you want to accept changes from other developers by performing a get operation as appropriate.  Ideally when you do this, you’ll update the entire configuration of source, and not just one or two files.  Why?  Because changes in one file typically depend on corresponding changes to other files, and you need to ensure that you’ve still got a consistent snapshot of source that is buildable and testable.

This is why the checkout operation doesn’t perform a get latest on the files being checked out.  Updating that one file being checked out would violate the consistent snapshot philosophy and could result in a configuration of source that isn’t buildable and testable.  As an alternative, Team Foundation forces users to perform the get latest operation at some point before they checkin their changes.  That’s why if you attempt to checkin your changes, and you don’t have the latest copy, you’ll be prompted with the resolve conflicts dialog.

The rationale is understandable but seems a bit idealistic.  Most developers I know aren’t getting latest on the full branch before each and every check out.  Instead they’re doing it once every day or so and otherwise not thinking about it.  This is why there’s an option change the default behavior.

Note: The steps discussed below are for enabling getting latest on check out on a developer’s workstation.  Refer to http://msdn.microsoft.com/en-us/library/bb385983.aspx for information regarding enabling the option at the server level.

To change this setting:

1. Open the options dialog in Visual Studio (Tools –> Options)
2. Expand the Source Control node
3. Select the Visual Studio Team Foundation Server node
4. Click the check box for “Get latest version of item on check out”

Although enabling the option will not eliminate the need to merge changes since it is entirely possible, perhaps even likely, that another user will check in changes prior to your check in it eliminates the need to merge with changes that were already in the repository when you checked it out.  This option also won’t eliminate the need to get latest on any file dependencies but if you were only getting one file at a time prior to check in anyway does that really matter?

Managing Shelvesets

Most version control systems have some mechanism for putting aside or sharing changes without checking them in and TFS is no exception.  Rather than creating patch files like we do in Subversion we “shelve” changes in TFS.

Shelving changes in TFS creates a shelveset.  Shelvesets are useful for preventing unrelated changes from conflicting or transferring code to another developer without checking them in.  In some ways I prefer shelving changes to creating patch files.  The two biggest advantages of shelvesets are:

• No need to remember where the patch file was saved since all shelvesets are in the same place
• Sharing changes is easier than dealing with permissions on network shares or e-mailing attachments

Creating a shelveset is easy because there are several readily available ways to do it:

• File -> Source Control -> Shelve Pending Changes…
• From the Pending Changes window (View -> Other Windows -> Pending Changes) switch to the Source Files panel and click the Shelve button.
• Right click on a file or folder in Solution Explorer and select Shelve Pending Changes…
• Right click on a file or folder in Source Control Explorer select Shelve Pending Changes…

Each of these options will display the Shelve dialog.  The dialog is virtually identical to the Check In dialog so I won’t describe its operation here.

Retrieving a shelveset isn’t quite as easy as creating one mainly because there are half as many ways to do it and they can be a bit difficult to find:

• File -> Source Control -> Unshelve Pending Changes…
• From the Pending Changes window (View -> Other Windows -> Pending Changes) switch to the Source Files panel and click the Unshelve button.

By default the Unshelve dialog lists the shelvesets owned by the current user.  Finding shelvesets from other users is just a matter of replacing the user name in the Owner name box.  Unfortunately there is no browse for user button so you’ll need to know the user name ahead of time.  Clicking the details button will display a list of the changes included in the shelveset and even lets you compare the shelveset version against the local copy.  Once you’ve found the desired shelveset click the unshelve button but beware, the built-in unshelve function will fail when there are local changes to any of the files in the shelveset.

The power tools provide a solution to this problem as well with the tfpt unshelve command.  tfpt unshelve is a command line utility solves the lack of merge support problem.  In its most basic form it displays a dialog very similar to the built-in dialog shown above. The only immediately noticeable difference is the lack of a delete button but there are more differences like the lack of compare support.

When we no longer need a shelveset we can delete it.  Shelvesets can be deleted from either the built-in Unshelve dialog or from the command line using the tf shelve command with the /delete option.

Tracking Changes

Providing tools for determining where a change came from is a key component of any version control system and this is an area where I think TFS excels.  TFS’s built-in tools for checking change history are actually very good.

Viewing history on a file or folder shows a list of changes typical to most version control systems.   The list itself isn’t particularly interesting.  It includes the changeset id, the name of the user that checked in the change, a timestamp, and the changeset comment.  As expected, we can also get a particular version.  We’ll examine some of the more interesting aspects of history and changesets later in the Program Management section but for now we’ll just look at the Track Changeset feature.

Track Changeset allows us to visually determine where changes came from in a multi-branch repository.  When a file is branched or merged Track Changeset will graphically display the originating and target branch(es) in either a hierarchy or timeline view.  By seeing how and when changes are propagated across the branches we can easily determine when and if a change was successfully applied to a given branch.

Also related to finding the source of a change is the annotation feature.  Annotating a file is roughly the same as the blame feature in Subversion.  Both systems show the contents of the file along with the changeset (revision in SVN).  What sets TFS’s annotate apart though is its ability to drill down into any changes from merge operations to show where a change really came from.

Although the power tools offer a separate annotation utility this is one place I have to recommend the built-in tool.  The power tools viewer is nice in that it shows much of the same information as the built-in viewer but doesn’t include any way to view changeset details nor does it drill down into merges.  The overall appearance of the built-in tool is much more polished as well.

Project Management

Although version control is a major component of TFS it’s just one part of a much larger system.  TFS is really an end-to-end project management system.  If you’re only using TFS for version control you’re missing out on the visibility into the overall health of a project that the project management components can give you.

Linking Items

One way that TFS provides visibility into a project is by allowing us to define links between objects.  Virtually any type of work item can be linked to another work item and TFS also allows linking to changesets or URLs.  Linking individual work items will help define the project plan and structure which is important from a reporting perspective but from a development perspective having links between work items and changesets is invaluable.

In the past my team has used a separate application for defect tracking.  QA would enter defects into the tracking system and if the issue required a code change we’d have to note the defect number in the revision comments and we’d quite often note the revision number in the notes on the defect.  If we ever needed to track down a change later we’d need to know one of two pieces of information (defect number or revision number) and visit two systems to find why a change was made or what the change actually was.  By linking changesets to work items in TFS we only ever need to visit one system to find the answer.  Furthermore, if the project is structured correctly we can easily access additional details about the change by drilling deeper into other links.

Linking objects is very easy.  There are several ways to link objects but for most of them we’ll usually add links by editing a work item.  On the edit work item screen is a tab labeled “All Links” that contains a toolbar with several buttons.  The two buttons we’re interested in are the “New” and “Link to” buttons.

As its name implies, the “New” button allows us to create a new work item and automatically create the link.  Through the dialog we can create new linked item dialog we can select the link type and corresponding link details.  A visual representation of what the link will look like is available for each link type.  We can also specify which work item type we’re linking to for each link type.  One thing we can’t do in this dialog is link to a changeset because changesets are only created by checking in changes.  In order to link to a changeset we need to look at the “Link to” button.

While the “New” button allows us to link to new items the “Link to” button allows us to link to existing items.  Most of the procedure is the same but linking to existing items gives us a few more options such as linking to changesets, URLs, test cases, or even individual versioned items.  This is great for linking to other work items but there’s a better, less intrusive way to link to changesets to work items.

Sidebar:

When my team started using TFS for project management my director requested that the pilot group update the time remaining and time completed fields on our tasks at the end of each day. This was met with a collective groan and you can probably guess how frequently time was updated.

One reason for the poor adoption is because we aren’t conditioned to record the time anywhere so many of us (myself included) simply didn’t think about it despite his repeated requests. Even when we remembered we had to think about the day and decide how much time to deduct for lunch and other interruptions then try to remember approximately how much time we’d spent on each task. Wouldn’t it be nice to record this information when it was still fresh in our mind rather than trying to remember it at the end of the day?

When we’re selecting work items during check in we can also open them for editing with minimal interruption to the task at hand.  Once I discovered this I started updating all of my tasks at check in rather than at the end of the day.  With this slight change I guaranteed that my tasks were as up to date as possible with the most accurate information possible.

When we’re ready to check in some changes our workflow generally looks something like:

1. Open the Check In dialog box
2. Enter a comment describing the change (you are entering comments, right?)
3. Verify that the correct files are selected
4. Click the Check In button

We can link work items to the resulting changeset from the Check In dialog box with a simple modification to the process:

1. Open the Check In dialog box
2. Enter a comment describing the change (you are entering comments, right?)
3. Verify that the correct files are selected
   — New Steps —
4. Click the Work Items button in the left panel
5. Click the check box for the corresponding work items (You may need to select a different query or enter some search criteria to find them)
6. Select the appropriate Check-in Action (Typically you’ll be selecting the Associate option)
   — End New Steps —
7. Click the Check In button

Despite having three extra steps the revised process usually only results in a few extra clicks.  Even if it’s necessary to refine the list it is far less interrupting to create the association between the work item and changeset from the Check In dialog than from the work item itself.  Creating the link when we check in our changes as part of our process also ensures that we actually do establish the link rather than waiting and possibly forgetting.

Once links are established it is very easy to navigate them from the All Links tab.  The links list is grouped by link type and all groups are expanded by default.  Double-clicking on any item will open the appropriate window for that item.  For changesets we see the changeset details window with all of its capabilities.

If it’s not immediately apparent how powerful the links are just work with it for a bit.  As more links are established finding data relevant to virtually any project related question will become easier.

Microsoft Project Integration

Linking work items in TFS forms the foundation of a project’s structure.  With work items we define time estimates, assign resources, identify dependencies, and project status.  We can view and manage all of this information through Visual Studio but for anything but simple tasks that can be quite cumbersome.  One of the most important features from a project management perspective is the integration with Microsoft Project.

Note: In order for Microsoft Project to interact with TFS Team Explorer must be installed.  Refer to http://msdn.microsoft.com/en-us/library/ms181675.aspx for more information.

From inside of Visual Studio we can open work item queries in Project by either right clicking on a query in the Team Explorer window and selecting Open in Microsoft Project or we can open the query, click the Open in Microsoft Office Button, then select the Open in Microsoft Project option.  We can also open an individual work item and click the Open Work Item in Microsoft Project button.  Any of these actions will open Project and Project will load a new worksheet containing the appropriate work items.

From within Project we create a new worksheet and select a Team Project through either the Team toolbar or menu.  Either option will display the familiar Connect to Team Project dialog.  After selecting a project we need to get the work items (again through either the menu or toolbar).  The Get Work Items dialog allows us to find work items by saved query, ID, or searching by title and type.  Once the list is loaded we can bring them into Project by selecting individual items or all of them.

The work items load into the familiar Gantt chart and we’re free to work with them as we were working on any other Project worksheet.  The big difference between working with TFS connected data and a standard worksheet is for refreshing and saving data.

Rather than saving the worksheet to save changes to the work items we need to publish them back to the server using the Publish toolbar button (or Publish Changes menu item).  Similarly, if we want to update the worksheet with the latest data we’ll need to click the Refresh toolbar button (or Refresh menu item).

Aside from managing work items the Project integration allows us to manage Areas and Iterations.  These can be found by clicking the Edit Areas and Iterations… item under the Team menu.

Alerts

With developers making code changes, managers updating project plans, QA entering defects, scheduled builds, etc… there is a ton of activity going on within TFS at any given time.  TFS includes an alert system that helps us keep up with all of it.

Despite the appearance of the dialog box used to create some of the more common alerts the alert system is actually quite robust.  Behind the basic dialog box is a full featured expression engine used to define the criteria that must be met in order for a notification to be sent.

Creating basic alerts for monitoring files and folders or work items is pretty straight-forward.  Once an alert is configured notifications will be sent whenever changes are made to the associated item.

Files/Folders

1. Open Source Control Explorer
2. Locate the File or folder to be monitored
3. Right-click the desired item and select Alert on Change…
4. Verify the field values and change any where the default is not desired
5. Click OK

Work Items

1. Open the results window for a work item query
2. Locate the work item to be monitored
3. Right-click the desired item and select Alert on Change…
4. Verify the field values and change any where the default is not desired
5. Click OK

Alerts are managed through the Alerts Explorer window which is accessed through the Team menu.  Existing alerts can be modified or deleted and we can also create new, more sophisticated alerts.  I encourage clicking around within the Alerts Explorer window and creating a variety of alerts to see all of the possibilities.

Wrap Up

One of the ideas behind TFS is to facilitate communication across the team and by using the tools more intelligently we can make sure that it has the information it needs to accomplish that goal and help us be more productive.  TFS certainly isn’t without its pain points but by incorporating the tips listed above we can reduce the impact of some of them or work around them altogether.

The TFS Power Tools will help keep the check-out model out of the way.  Changing the default compare and merge tools makes resolving conflicts easier.  Shelvesets let us store away or share a batch of changes without checking them in.  Linking work items with changesets and other work items helps us verify that the project is on track and answer questions about what happened later on.  Alerts proactively keep us informed of what’s going on.  None of these are all that useful on their own but when used in combination their power multiplies and their value becomes apparent.