TFS 2012 Re-apply changes from a change set for continuous integration

Question

I have a project in TFS 2012 and using TFS for source control. I have a single branch of code.

I want to find an easy solution to the following scenario.

Here is an example branch with half a dozen change sets.

This is how the story goes so far (pretend the user is not all me!)

1. 5219 Kicks off a build and test run.
2. There has been a number of changes (5220,5221 and 5222).
3. The test run finishes for 5219 and we are green - all happy.
4. Our CI then runs a test run for 5222. It goes red. Therefore I know my problem is in one (or any) of 5220, 5221 and 5222.
5. As matter of procedure we rollback to the last known green (5219)
6. After a bit of investigation each of the people responsible for 5220, 5221 and 5222 are given their product backlog items back - all is good, we have found something new about our changes (i.e. it has broken something we were not expecting).
7. Because we are green another piece of work occurs (5235).

All good so far, but what happens to the person who, say, has been given 5221 back.

What I want them to do is get up to date with the latest, with any current changes, and re-apply the changes from the 5221 change set (as you can in subversion).

I can work out how to 'get' change set 5221 using the powertools tfpt getcs command. This gives me a different workspace and server version file, but doesn't attempt any type of merge. I can work out how to 'get this version' for the branch which will put the whole branch back to that point in time. I cannot work out how to merge the changes that occurred as part of 5221 into the latest version (but still local to me).

Any ideas (other than upgrading my TFS and moving away from TFS source control - which will happen, but not in the very short term)? I would prefer to steer clear of multiple branches too. My real projects are large, monolithic and not to friendly too branching in TFS.

Answer 1

I'm afraid you need to update the changes in 5221 to the latest version manually. There is no automatic way.

Get the latest version into your workspace, compare the changeset 5221 with the latest version, then copy and paste the difference from 5221 to the latest version, and check in to TFS.

Answer 2

Use a gated check-in instead of rolling back changes. Gated check-in will automatically reject any changes that result in a broken build.