views:

40

answers:

1

In TFS 2010 we have a development branch where all development is done for one product. I want to merge some of these changes to a release candidate branch, so it can be tested and rolled out. Therefore I would like to merge all changesets that are linked to specific work items we want to put into the release candidate.

I can track all changesets for a specific work item but I cannot easily merge them into the RC-branch. I can neither drag more than one changeset in the hierarchy tracking view nor pre-select the changesets in the Merge Wizard. By default it always wants to merge all changesets UP to the dragged one, which is definately not what I want. Since it could be dozens of changesets I don't want to select them all manually.

Is there any way to do this in the "right" way?

+1  A: 

What you are talking about is a "cherry-pick" merge. Overall, cherry-pick merges are not a best practice, so if you are thinking this is going to happen lots, you should probably revisit your branching strategy (e.g. branch on feature, versus branch on release). Then you can simply merge entire branches instead of doing cherry-pick.

You are going to find that TFS does not support this type of merge very well. When you merge on changeset, it will merge all files up to and including that changeset. You may be able to get away with labeling the files in the specific changesets and merging based on label, but I'm doubtful that will work.

We have a situation in my organization where we needed to support this type of functionality. Ultimately, we wrote a utility that allows us to pick and choose files from multiple changesets and merge them to a branch. The code to do this is relatively straightforward.

Robaticus
In addition to Robaticus, revise your release strategy. I would advise to deploy all features within a release to a release candidate, so you also perform an integration test on your application.
Ewald Hofman
Thanks guys, we finally came to the same conclusion. Now we have to find a alternative for our current branching strategy. But I am afraid of having dozens of feature branches later. One way could be to delete the branch once it's merged into main dev. In addition we could create feature branches for those features that cannot be included in the next release but should be started already.
JensMig
We literally spent months deciding on a branching strategy. It was the hardest part of implementing TFS.
Robaticus
@JensMig Do you have the capacity to be executing multiple features at any given moment for a single product? If so, make sure you have good communication between teams to thwart merge conflicts. Also try to partition product features such that you can minimize conflicts. If you don't have that capacity (1 team of 5-10 members), I would HIGHLY recommend finding out which feature is the MOST important and work it until it's done - shippable. Better to have 1 feature ready to ship than 5 almost ready.
Ryan Cromwell