TFS 2010

TFS2010: Dealing with the Check-out Model

Edit (8/31/2010): The content of this post has been incorporated into my more comprehensive Everyday TFS post.  If you’re looking for a general guide to being more productive with TFS on a day-to-day basis you may consider starting there instead.

TFS has been giving me flashbacks to the days when we used Visual Source Safe. After years of using Subversion one of the first things TFS did was remind me why I hate the check out model. The check-out model offers some nice features such as identifying who else might be working on a file but it really just gets in the way most of the time. When I’m in the zone the last thing I want is to have my train of thought derailed just to check out a file. I don’t want to think about source control until it’s time to check in my changes.

Visual Studio Team System helps alleviate the problem by implicitly checking out files but what happens when files are under source control in TFS but edited outside of Visual Studio? Most of the time this requires going to Visual Studio, finding the file in the Source Control Explorer, and checking out the file or issuing the tfs checkout command from a command prompt. I typically open these files through Windows Explorer or through the corresponding application’s open file dialog so neither of the options really fit into my typical workflow. Wouldn’t it be nice to check out files from Windows Explorer?

Note: Yes, it’s possible to remove the read-only attribute from the file but that’s at least as intrusive as the other methods and has the added benefit of confusing TFS.

TFS Power Tools includes shell integration. Like the shell integration for other version control systems Windows Explorer displays files and folders under TFS source control with icons decorated to indicate their status. The integration isn’t quite as full-featured as what we get with Tortoise SVN but it’s enough to be productive. Primarily it allows getting the latest version, check-in/out, undo check-out, and comparing files with the server version. Conflict resolution, adding, renaming, moving, and deleting files are also possible. I still hate the check out model but the shell integration has made it a bit less painful.

A second headache with TFS’s check out model is that EVERYTHING needs to be checked out in order to do anything with it. Under normal circumstances this is fine but what if you’re only making a small, temporary change that you know won’t be checked in – at least not on purpose anyway? I know I’m not the only one that regularly adds and removes debugger; lines in JavaScript files while I’m bug hunting. There are also those pesky files that Visual Studio automatically checks out but never actually changes. When it’s time to actually do a check-in we’re left with a bunch of unchanged files to sift though to find the ones we actually care about.

TFS is supposed to only check-in files that have actually changed but if you’re like me you like to make a quick pass over your changes before actually performing the check-in. Wading through unchanged file after unchanged file is just a frustrating waste of time. I also like to keep my digital workspace tidy (my physical desktop is a different matter) and all of these unchanged files are unnecessary clutter. TFS Power Tools offers a solution for this too.

The tfpt uu command line utility will examine the pending changes in a workspace and undo any unchanged files. By default the utility will get latest on the workspace before comparing files to the latest version. There are a handful of arguments for controlling aspects of its operation, of note are /noget which prevents the utility from getting latest and /recursive which checks the folders in the workspace recursively. For full information regarding the utility’s options refer to its documentation (tfpt uu /?).

Since I’ve started using TFS I’ve really come to rely on the functionality that the power tools provide. At this point I have very little doubt that the power tools are absolutely essential for anyone working with TFS. Both the shell integration and the tfpt uu command have become essential parts of my workflow since they help minimize the frustrations associated with the check out model.

TFS2010: Shelving

Edit (8/31/2010): The content of this post has been incorporated into my more comprehensive Everyday TFS post.  If you’re looking for a general guide to being more productive with TFS on a day-to-day basis you may consider starting there instead.

A nice feature of TFS is that it allows developers to put aside, or shelve, a set of changes without actually committing them. This can be useful when you need to revert some changes so they don’t conflict with another change or when you need to transfer some code to another developer or workstation.  Like so many things in TFS the shelve feature can be useful but is hindered by poor tool support.  Hopefully the tips presented here can reduce some of the headaches associated with the feature and help you use it to its full potential.

Microsoft made it really easy to create a shelveset.  The Shelve dialog is virtually identical to the Check-in dialog so I won’t go into detail about its operation.  Shelvesets can be created through any of the following methods:

  • 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…

Although Microsoft made it easy to create shelvesets they really fell short on retrieving them.  Unless you’ve been observant when using TFS you’ll probably begin by hunting for the elusive unshelve button.  Unlike when creating a shelveset where there are access points in places we use regularly, there are only two places to go (that I know of) for retrieving one and they’re both kind of buried.

  • 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.

The unshelve dialog lists all of the shelvesets created by the user listed in the Owner name field.  By default the owner name is set to the current user but replacing the name with another user name will allow finding the shelvesets created by that user.  Unfortunately there is no way to search for user names so you’ll have to know the name before opening the dialog.

After locating the desired shelveset you can examine its contents through the details button, delete it, or unshelve it.  The unshelve command doesn’t really play nice with files that have local changes.  In fact, if you try to unshelve a file that has changed locally you’ll probably get an error dialog talking about a file having an incompatible local change.  Luckily there’s a work-around that, like so many other things in TFS,  involves TFS Power Tools.

  1. Open a Visual Studio command-line
  2. Navigate to the appropriate workspace
  3. Enter the command tfpt unshelve
  4. Locate the shelveset to unshelve
  5. Select the unshelve option – a second dialog box will open listing any conflicts needing resolution

TFS2010: Reverting a Branch to a Folder

My team is in the process of transitioning from SVN to TFS for version control. One lesson we just learned the hard way was that TFS doesn’t support the concept of nested branching. Early on in our transition I branched an individual folder and things had been going quite smooth until yesterday when we needed to branch the main folder to spin off a side-project and TFS gave me a nice message about the folder already containing a branch. Uh oh…

I spent a few hours grasping at straws trying to get out of this situation. I even tried reverting a couple of changesets with the rollback functionality included in the TFS 2010 Power Tools but nothing seemed to get rid of the old branch. Eventually I stumbled across this MSDN forum post that said the command to change a branch back to a folder is just a matter clicking File -> Source Control -> Branching and Merging -> Convert to Folder in Visual Studio. After selecting that menu item the branch icon changed back to the standard folder icon and I was able to create the new branch.  Had this option been available in the context menu I’d have found it right away rather than spinning my wheels but now I know it’s there should I need it again.