It’s been a number of years since I worked with TFS. Now that I’m back in that world one of the things that has bitten me is that by default any tasks tied to a check-in are resolved by default. Automatically marking tasks as complete has left me scratching my head in bewilderment as I wondered why a task I’m actively working on was no longer listed under my tasks. I can see the utility of this behavior in some circumstances but I often make incremental check-ins as I work through more complex tasks so clearly I don’t want checking in my changes to automatically close the task.
Since relying on my memory to change the check-in action from Resolve to Associate clearly isn’t adequate here I looked for some way to change the default behavior. I found that there are two ways to achieve this, neither of which are obvious.
The first method is to remove the Microsoft.VSTS.Actions.Checkin action from the work item template. The other method applies only to the client machine but requires a registry edit. Neither option is particularly great but given that the first option requires you to have authorization to modify the template and applies to each user of the template, I opted for the second approach.
To disable the default resolution option you need to locate HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction and change the ResolveAsDefaultCheckinAction value from True to False. After making the change, restart Visual Studio and the Associate should now be selected the next time you try adding a work item to the check-in.
I’ve been using TortoiseSVN for years. One place I’ve found it lacking in the past though was when I wanted to remove unversioned files from my working copy. This has generally been a nuisance but I’ve dealt with it. A few days ago, I needed to recover from a merge gone wrong and got serious about finding a better way.
Recently I’ve been working with a third party component vendor to resolve a defect. They requested that I create a sample project illustrating the issue and send it to them as a zip archive. Building the project was easy but I didn’t want to send all of the extra stuff that goes along with it. In other words, I wanted a snapshot of the current revision but without the source control bindings. I knew how to do this with Subversion but how did Mercurial handle it?
Since I started using Mercurial a few months ago I’ve fallen in love with it. There was a bit of a learning curve for getting up and running but I found that the Tortoise tools are really intuitive and eliminated some of the pain. Most importantly though, Mercurial addresses the single biggest problem I had when working away from home – no repository access.
When my team reverted back to Subversion the first thing I missed was the Visual Studio integration from TFS. CollabNet provides AnkhSVN to fill that gap by exposing most common source control operations directly through the IDE. I’ve been using AnkhSVN successfully for a few months but one thing that always bugged me was the default compare tool. I love WinMerge and the default merge and compare tool just didn’t, well, compare. Thankfully the merge and compare tools thank AnkhSVN uses are configurable.
AnkhSVN adds a Subversion User Tools page to the Source Control folder in the Visual Studio options dialog. From here we can select the tools to use for:
Not only does AnkhSVN provide a list of popular tools including WinMerge and KDiff, it also attempts to determine if any of them are installed and marks any it can’t find with “(Not Found)”. To change the tool just select it from the list or enter the path to your favorite utility.
Each of the tools are preconfigured to run with a fairly thorough set of arguments but if we want to customize them we can click the corresponding ellipsis button to open the Command Editor. AnkhSVN uses the macro paradigm to inject a variety of variables into the argument list for the selected editor. Its macros follow the traditional $(name) format so it should look familiar to anyone familiar with configuring external tools from Visual Studio’s Tools menu.
Ever since I found these settings and replaced the default tool with WinMerge I’ve been much happier. AnkhSVN is a much more natural extension of my workflow than TortoiseSVN so being able to use WinMerge simplifies the process immensely.
Mark your calendar for the second meeting of the Indy TFS user group on December 8, 2010. I will be presenting some tips for improving the TFS version control experience. In particular we’ll examine enhancing version control with the TFS Power Tools, replacing the default compare and merge tools, tracking changesets, and integrating some project management features into the version control workflow.
500 East 96th St
Indianapolis, IN 46240
Doors open at 6:00 PM with the meeting starting at 6:30. Pizza and drinks will be provided.
One of the complaints I’ve heard about TFS 2010 version control is that getting latest doesn’t show a listing of what was changed. This is untrue. TFS does indeed show such a listing it’s just not as obvious as in other version control systems.
After getting latest, jump over to the output window and select the “Source Control – Team Foundation” option from the “Show output from:” menu. The output window will then display the action taken and file name for each affected file.
It would be nice if TFS would present this information in a sortable/filterable grid format instead of relying on the output window but having the simple listing is typically more than enough. The output window itself is searchable so if you’re looking for changes to a specific file or folder just click in the window and press Ctrl + F to open the find dialog.
Now the next time someone claims that “TFS doesn’t show me which files changed!” you can tell them to check the output window.