Wednesday, April 30, 2014

Discarding merge of a changeset in TFS

On a project I work on, we have just had the first branch of my life. The merge features in TFS helps me merge needed changes between the two branches and it works just perfect.

As part of the branch I have had to assign a particular range for label id's in one of the branches. This is to avoid conflicts when merging the label files. You set up the label id range from Version Control / System settings / General. Changing this, triggers a change to VCSDef.xml which is also under version in TFS.

This is obviously not a change that I'd ever want to merge. Fortunately there is a way to tell TFS to discard the change when suggesting what to merge. There is no UI for the command, so open a Visual Studio command prompt from the workspace folder to use and enter the following:

tf merge /discard /version:C1134 /recursive SourceBranchName TargetBranchName

This also triggers a change, so you must check that change in. And that's it. The changeset is not suggested for merge between these branches again.


Robesz said...

Hi Palle,
I would like to ask you about this label range technique because we try to use the same logic on our "two-branches" TFS system.
Should we set up the label-ranges on both branch to keep label-ids separated?
Main: 0 - 1000
Branch2: 1001 - 2000
A few days ago, we set up just the second one and it works fine.
(the protection of VCSDef.xml file is ok)
We received the 1001-1018 labels while check in. Fine!
But the developers - on the Main side - received the 1018-1022 :-)
The Label system used the largest number from the file.
So, what's your Best Practice to resolve this issue?
Many thanks from Hungary!

Palle Agermark said...

Sound a bit Odd the Main should be depending on labels from your Branch2.

In any case, if you are going to use TFS to merge code back and forth between the branches, you'd want separate ranges,