Developer Drain Brain

November 23, 2009

Change tracking in TFS

Filed under: Development — Tags: , , , , — rcomian @ 2:16 pm

One of my main bugbears with source control is knowing where my changes are. I don’t mean just having a good idea, I mean actual empirical evidence that I can look at and easily convince someone else that changes have been moved from the project branch to trunk, and from trunk to release.

Now this is always possible by looking at the code, but that just doesn’t scale – it can easily take days to work out what’s in a particular release, and by the time that’s finished the world will have changed anyway. We need something high level, something that says this branch contains these changes from these locations. TFS goes some way to addressing this with a nifty visualisation in the new 2010 suite. Given a changeset, you can follow the merge history of that changeset across the branches of your project.

This is excellent if you’re looking at a particular change and want to know where it is. You can easily see that it has been flowed in the right direction, and can see how much of a mess you’re getting yourself into. This visualisation also handles partial merges by showing them in yellow for the time that they’re partial (hopefull they’ll get fully merged after a while, letting them go green).

If you want to know where a particular change has made it to, this view is perfect. In my experience, however, we rarely want to know where a single changeset has gone, we’re much more interested in where a workitem has gone. Although we’d all love to think that there’s a 1:1 correspondence between workitems and changesets, it just aint gonna be so, regardless of how you work. MS are working on this, of course, although I’m not holding my breath for the initial 2010 release.

The other problem is again one of scale. Whilst this view is very useful, one thing that we need for a release is a report on all the items which have been merged into this release from trunk (and conversely, what’s missing). Ideally this should be at a workitem level as well, but a changeset level report is a good start. Subversion has this with its mergeinfo command. Tortoisesvn shows each revision and greys out the ones that have already been merged. Git has an incredibly detailed view of all the changes that were made on parallel branches. I’m not sure if that’s any use in telling you what’s missing, but it’s wonderful for knowing what’s in. These all work on the changeset level, however.
I haven’t found anything equivalent in TFS yet. The information is available in TFS, so it’s likely trivial to build it manually.

All of this tracking is of no use, however, if your changesets mean nothing more than it was Friday night and were preparing for the weekend. Also, a commit comment of “some changes” isn’t going to be useful for working out which changesets you’re looking for. If you’ve never felt the need to be disciplined in making a changeset be a single unit of functionality before, perhaps this can inspire you as to why it might be a good idea.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: