Tuesday, August 16, 2016

TFS Branching issue: What does Reparenting a branch mean in TFS 2013

I had a strange problem with the TFS branching mechanism and want to set it right, the reparenting of a branch option in TFS 2013 helped me solve it.
This is the branch hierarchy that we setup in tfs source control.

<Project>
| Dev
| > 1
| Trunk
| > 1
| Rel
| > 1

Since, this is a relatively new product development, all developers worked on Dev\1 branch on a single feature. Once the feature is completed, Dev\1 branch will be merged into Trunk\1 and then further again into Rel\1 to get it released for testing. Issues from testing are directly fixed in Rel\1 branch and on success released to production. As you could see this is like any other typical TFS branching for source control.

Now coming back to the problem, we had to do a list of small features clubbed into one backlog item and for clarity sake, lets call it "feature A". While the dev team were almost 75% done on that feature, a new urgent feature request came and the development had to be started concurrently and not wait until "feature A" is completed. Let us call the new feature as "feature B". Since feature B had a dependency on things that are being done in feature A, and since "feature A" isn't yet fully ready to be merged into Trunk\1, We created a Dev\2 branch from Dev\1, instead of the usual branching from Trunk\1. The project hierarchy is now as follows:

<Project>
| Dev
| > 1
| > 2 (Dev\2 is at same level as Dev\1 although its parent is Dev\1 branch, see branch hierarchy screenshot below)
| Trunk
| > 1
| Rel
| > 1

If you click on View Hierarchy TFS context menu for Dev\2 branch it shows as below:


Regular merges happened from branches Dev\1 to Dev\2, but not the other way to avoid release issues for "feature A" and we could release feature A independent of any changes being made in Dev\2.

After sometime, "feature A" was completed, merged into trunk and released. But, If we had to release the feature "feature B" that is being done in Dev\2 then we had to merge it into Dev\1, then into Trunk\1 and further. Instead if we could have a mechanism that would make Trunk\1 as the parent of Dev\2 instead of Dev\1, then the process gets streamlined. It is for this purpose, Reparenting is used.

The option to Reparent is available from the context menu in source control explorer as shown in screenshot below. 


But, when you click the option to reparent, the list view doesn't list Trunk\1 as an option to reparent. So, in order to get that branch name listed as an option in that list, Do a baseless merge either through command line or the UI (It doesn't get listed by default, but you could browse to the location, by using the browse button in the merge dialog, tfs warns that you are doing a baseless merge, which you could safely ignore). After the baseless merge and checkin, the Trunk\1 is now listed as an option as shown in the below screenshot. 

Select Trunk\1 and click Reparent.

VoilĂ ! Trunk\1 branch has now adopted Dev\2 as its child ! ! ! :)

No comments:

Post a Comment