Partial Merges in TFS – A Guide

Ladislau Szomoru (CSS TFS Escalation Engineer, Hungary) is at it again today, building on a previous post around TFS merge…

On April 15th 2009 we posted an interesting article written by Philip Kelley from the Team Foundation Server development team on how to track down merge history using tf merge and tf merges. In case you did not have the chance to read I would recommend you go over it before reading this post.

One topic that was not discussed by Philip were partial merges. A partial merge is recorded when only some changes from a changeset are merged into the target. In this post I will try to describe some of the more common scenarios in which you can end up with partial merges.

Scenario1

Consider we have two branches Main and Dev and they both contain two files. The files have been edited in the Dev branch and we are about to perform a merge operation from Dev to Main.

First we get the merge candidates

C:\Samples >tf merge Dev Main /recursive /candidate

Performing the merge operation will add a pending change for each of the two files. For some reason we decide that we do not want to merge the changes in File2.txt so we undo the pending change in the “Pending Changes” window. We go ahead and we check-in the merge.

Now if we take a look at the merge history of Main we will see the following:

C:\Samples >tf merges Dev Main /recursive

Note: It is important to note that in Team Foundation Server 2008, you need to specify both the source and the target for the tf merges command, in order to see the partial merges. This was a decision made by the product group in order to improve the performance of tf merges.

In the output you will see an asterisk (*) next to changeset 138 which indicates that it is a partial merge. That means that only part of changeset 138 has been merged into changeset 139. If we take a look at the merge candidates from Dev to Main, we will see that even though we already merged changeset 138 to Main, it is still a merge candidate. This is caused by the fact that the merge engine detected that there are still some changes in changeset 138 which were not propagated from Dev to Main.

C:\Samples >tf merge Dev Main /recursive /candidate

Scenario 2

Consider that you have two branches Main and Dev, each of them has two folders (Feature1 and Feature2) and each feature folder contains one file. We edit both files from the feature folders (Dev\Feature1\feature1.txt and Dev\Feature2\feature2.txt) and check-in the changes.

There are many scenarios in which a merge operation is performed at the feature level first and not from the top of the branch. Let’s see what happens if we perform the merge at the Feature1 level. Let’s get the candidates first:

C:\Samples>tf merge Dev\Feature1 Main\Feature1 /candidate /recursive

Now perform the merge operation at the Feature1 level. You will notice in the Pending Changes window that only the edit done in the Feature1 folder will be merged. Complete the merge.

If you take a look at the merge history of the Feature1 folder you will see that all changes from changeset 142 have been merged into changeset 143.

C:\ Samples >tf merges Dev\Feature1 Main\Feature1 /recursive

However if you take a look at the merge history of Main you will see that only parts of changeset 142 have been merged into changeset 143. This is normal as changeset 142 has some changes - the edit of the file in the Feature2 folder - which were not delivered.

C:\ Samples >tf merges Dev Main /recursive

In case of a partial merge, how do we figure what changes have been merged and what changes from the changeset were left out. The only way to achieve this is to diff the contents of the changeset that was partially merged, and the contents of the changeset that was generated as the result of the merge.

In case of our second scenario we need to check the details of changeset 142 and 143…

If you diff the list of files under Items, you will see that only the chances for file1.txt have been propagated. In case we choose to perform the merge either at the Feature2 folder level or from the top of the branch the changes made on file2.txt will be merged.

A frequent question that we get from our customers is “Why is changeset xxx listed as a merge candidate when the changeset has already been merged” ? The answer is that if changeset xxx is marked as a merge candidate it means that it contains some changes that were not merged from the source to the target. It is possible that only parts of the changeset have been merged.

Technorati Tags: Team Foundation Server,TF Merge,SCC