Blog Archives

October Speaking Engagement – Indy TFS

I’ll be presenting Web performance and load testing in Visual Studio 2010 to the Indy TFS user group on October 5, 2011.  In this talk we’ll explore some of the basic test management capabilities in Visual Studio 2010 before diving in to building and executing both Web performance and load tests.  Some areas we’ll examine include:

  • Test recording tests
  • Parameterizing tests
  • Extraction rules
  • Validation rules
  • Data binding
  • Load test scenarios

Location

Microsoft Office
500 East 96th St
Suite 460
Indianapolis, IN 46240
[Map]

Doors open at 5:30 PM with the meeting starting at 6:00.  Pizza and drinks will be provided.

Register at https://www.clicktoattend.com/invitation.aspx?code=157231.

I hope to see you there!

TFS Power Tools Get a Facelift

Today the Visual Studio Facebook page had an announcement about the availability of an update to the TFS Power Tools.  Although I’ve been back in SVN-land lately this update is still pretty exciting.  Given that my most popular post is Everyday TFS I thought my readers would find it just as interesting.

Per the announcement the March update focuses on three main areas:

  • Addressed reported issues in the Backup/Restore Power Tool
  • Fleshed out the Windows Shell Extension for version control
  • Took the first step on the path to a bunch of new TFS Build Power Tools

Read the rest of this entry

Indy TFS Discussion Resources

Thanks to everyone that came out to Indy TFS on December 8.  I hope everyone that attended found some value in it.

A few people asked for the list of resources I gave at the end of the session so without further ado:

Enjoy!

Which Files Changed?

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.

Upcoming Events in Indianapolis

There are a few interesting software development related events coming up in Indianapolis over the next few weeks.

 

Indy TFS User Group

Date/Time:
10/13/2010 6:30 PM

Location:
Microsoft Corporation
500 E. 96th St.
Suite 460
Indianapolis, IN 46240
[Map]

Web Site:
https://www.clicktoattend.com/ invitation.aspx?code=151376

The first meeting of the Indianapolis TFS User Group will feature Paul Hacker introducing many of the Application Lifecycle Management tools in Visual Studio 2010.

I’ve been reading Professional Application Lifecycle Management with Visual Studio 2010 and am pretty excited about many of the features.  I hope to use this session to expand upon what is included in the book.

This event is free to attend.  Follow the link to the right to register.

IndyNDA

Date/Time:
10/14/2010 6:00 PM

Location:
Management Information Disciplines, LLC
9800 Association Court
Indianapolis, IN 46280
[Map]

Web Site:
http://indynda.org/

The October IndyNDA meeting will be presented by the group’s president, Dave Leininger.  Dave will be discussing ways to graphically represent complex relationships in data.

Three special interest groups (SIGs) also meet immediately following the main event.  The SIGs were on hiatus last month so I’ll be giving my introduction to dynamic programming in C# talk this month.

IndyNDA meetings are free to attend thanks to the sponsors.  No registration is required.  Regular attendees should note the new location.

Indy GiveCamp

Date/Time:
11/5/2010 – 11/7/2010

Location:
Management Information Disciplines, LLC
9800 Association Court
Indianapolis, IN 46280
[Map]

Web Site:
http://www.indygivecamp.org/

“Indy GiveCamp is a weekend-long collaboration between local developers, designers, database administrators, and non-profits. It is an opportunity for the technical community to celebrate and express gratitude for the contributions of these organizations by contributing code and technical know-how directly towards the needs of the groups.”

I can’t be participate in this year’s event due to prior family commitments but I’ve heard enough good things about the GiveCamp events in other cities to know that it’s a great cause.  There is still a need for volunteers so if you can spare the weekend please volunteer.  One of 18 charities will thank you for it.

TFS2010: Branching Guide

After a lunch-time discussion about branching strategies with TFS I started looking for a good branching guide.  The ALM Rangers put together a thorough guide based on lessons learned from real-world deployments.  The guide provides general guidance for selecting one of four increasingly complex strategies:

  • Basic: Main, development, and release branches
  • Standard: Basic + service pack branches
  • Advanced: Standard + hot fix branches
  • Mature: Single main branch with multiple development, service pack, hot fix, and release branches

Equally important is the discussion about when to create additional development branches:

  • Breaking changes: A change in a common library will break other parts of the system until they are updated to reflect the change
  • Segregated feature work: A team wants to control when its features are released to other teams
  • Next version development: Allows development on the next version to start before the release branch is created
  • Scratch” or Temporary Branches: Prototype work, etc…

If you’re looking for a decent branching strategy guide I recommend starting here.  The document is a pretty quick read and well worth the time spent reviewing it but make sure you take some time to review the supplemental materials as well.  They have a lot of good information that can help clarify or extend the information in the main guide.

Guide: http://tfsbranchingguideiii.codeplex.com/
ALM Rangers: http://msdn.microsoft.com/en-us/vstudio/ee358786.aspx

TFS2010: Everyday TFS

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

TFS Power Tools in Extension ManagerThe 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?

TFPT Shell ExtensionsAside 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.

Configure User Tools ButtonCustom 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.

Configure ToolExtension: 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. Get Latest on Check OutOpen 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.

UnshelveRetrieving 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

Track Changeset - TimelineProviding 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 - Hierarchy 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.

New Linked Item 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.

Add Linked ItemWhile 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.

Add Alert to FolderFiles/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

Add Alert to Work Item 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.

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.

Follow

Get every new post delivered to your Inbox.

Join 628 other followers

%d bloggers like this: