Dude, where’s my code? Changeset tracking to the rescue!

There’s a new feature in TFS 2010 that I’ve mostly ignored but I think is super powerful.  The new “Tracking Changeset” window gives us a visualizer that shows us exactly what code branches your changeset has made it to.  Not only that, but there’s also a way to look at a timeline that shows you when your code was merged to each branch, in a visual way, of course!

So how does this work?

Well, if you have a branch that was created in TFS 2010, then this is turned on automatically.  If you created your branch prior to migrating to TFS 2010, you need to turn this on, it’s pretty easy to do:

  • From Source Control Explorer, right-click on your parent branch and select “Branching and Merging”, and then “Convert to Branch”
  • On the “Convert to Branch” dialog box, enter a description and click Convert

That converts your “old-style” branch into a TFS 2010 branch, and now you open up whole set of new branching features.  For example, you can now right click on that branch again, and instead of the “Convert” option, you now see a “View Herarchy” option.  Selecting that option gives you a nice diagram showing you your branches and how they relate to eachother:


That’s cool, but really not that exciting…It just shows that I have a main branch, that is the parent for a development branch and a couple of releases.

So now let’s look at changeset visualization:

If you right click on your development branch in Source Control Explorer and look at history, there’s a new icon on the toolbar called “Track changeset” image .  Note that this icon is always available, but if you try it on a folder that is not a branch (a TFS 2010 branch), you will get an errror: TF247005: At least one changeset cannot be tracked because an item is not contained in a branch.  You need to identify a container folder and convert it to a branch.  So if you select that option on a Branch folder, you will see this:


The diagram shows that I checked in Changeset # 16 into my Development 1.1 branch, I merged it to Main with changeset # 17, and then moved it to to my release branch as part of changeset #18.  On top of that, I can double-click on  the changeset item on the visualizer, and it will give me changeset details.  You also get an option on the toolbar called “Timeline Tracking”.  It gives you a different view of your changes:


This shows you the same information as the previous chart, but in a timeline way.  So now you know exactly when each changeset was merged (In this sample, i moved it all around the same time, so you only see one date, but you would see a bunch of different dates at the top if you all your merge operations were done over time).

Ok, so it gets even better.  Since TFS allows you to associate a changeset to a workitem, you can do the same type of tracking from your workitem.  To do this, open up a workitem that you know is associated to a changeset.  Click on the Track Work Item icon image and you get this in the Hierarchy Tracking view:


This tells me that as part of my workitem, I’ve checked in changesets 16, 21, 24 into my development branch and then merged them to main as part of changeset 17 and 22.  Note that the asterisk next to the 22 means that not all changes have been merged yet.  It then says that I merged changes to Release as part of changesets 18 and 23.

Now let’s look at the Timeline:


This shows me all my changes sets and when they got merged to each branch.  It shows that changeset 24 was checked in to the development branch but it hasn’t made it to any of the other branches. 

Before there was a way to see this, but you had to dig for it.  It’s just so impressive how much work TFS is doing behind the scenes for us.   So next time someone wonders whether their code made it to another branch, use the tools and find the information pretty quickly and easily!

About esteban

Esteban is the Founder and Chief Technologist at Nebbia Technology, an ALM consulting and Azure-powered technology company. He is a software developer with a passion for ALM, TFS, Azure, and software development best practices. Esteban is a Microsoft Visual Studio ALM MVP and ALM Ranger, Pluralsight author, and the president of ONETUG (Orlando .NET User Group).

Leave a Reply

Your email address will not be published. Required fields are marked *

Are you human? *