Team Foundation Server issues – changesets getting squashed

This is the second part in a series of posts about Team Foundation Server.
This time I want to talk about how TFS merges changesets into a new changeset. See the scenario below.


In this scenario a branch has been created from the trunk. In this branch 4 changesets have been created. Later on, these changesets are merged back to the trunk. TFS creates a new changeset (E) which is the combined result of the changesets A to D.
Now what if you find a bug in the trunk sometime after changeset E? You can build an older version of the trunk and determine that yes, the problem is indeed in changeset E. But you would like to know what specific changeset introduced the bug. Was it changeset A, B, C or D?
It turns out that there is no easy way to determine this in TFS 2005/2008. TFS has combined all the information in the new changeset. Sure, if changesets A – D touched different files the analysis will be easy, but if the merge contained a lot of changesets the analysis will be a lot harder.
This problem has finally been solved in TFS 2010. You will be able to see how a specific changeset travelled through all the branches.
For those stuck with TFS 2005/2008 a simple tip:
When merging make a note of the changesets being merged by adding the changeset numbers to the login comment. This way, you at least have a fighting chance.

Comments

Popular posts from this blog

Small tip: use QueueBackgroundWorkItem for asynchronous work in ASP.NET

Why you should use git merge --no-ff when rebasing.

Using NUnit for your tests in Team Foundation Service with a Git repository