This project has moved and is read-only. For the latest updates, please go here.

Reparent or OK to treat the original ancestor branch as a child branch?

May 17, 2011 at 7:03 PM

Question:  Under what circumstances (if any) would you consider recommending a "virtual reparenting" (treat the original parent or ancestor branch as a child branch and just reverse the terms RI and FI for this "virtually reparented" branch) or is it less risky to go through steps (and related risks) to reparent the ancestor branch?


  1. We currently have a Mainline/Main branch that is a child of the ancestor (current root) branch named Prod.
  2. There is a reasonable chance that future livesite hotfixes from the ancestor root branch will need to be merged back into Main (new root branch that used to be a child of Prod) for up to a year.
  3. I expect only a small number of merges (<5) from original parent/ancestor branch to the Main branch.

Known Issues:

  1. TFS Branch diagrams will inaccurately show original parent/ancestor as parent.
  2. Anyone with write access to the original parent/ancestor has risk of forgetting the "virtual reparented" relationship and accidentally merging changes into this branch.

Thoughts: Technically I don't think there are any differences between parent and child branches. These concepts are designed to make complicated versioning relationships easier for humans to conceptually work with (hence reduce risk of doing wrong way merges). Even though this is the ancestor branch merges only from Prod to Main ("Forward Integrations" technically due to "virtual reparent") it should be OK as long as only one Dev has rights to do these merges and RIs from Main to Prod are forbidden after virtual reparenting.

Reparent scheduling assertion: If reparenting a parent branch that is periodically merged with child branch then the best time to plan reparenting is immediately after both FI then RI (after which branches should have least number of conflicts to resolve). 

Please comment if this assertion is inaccurate or incomplete.

May 17, 2011 at 7:15 PM

I think the most important distinction comes when you have more than one parent and one child. When I explain branching I like to stress the point: When you have a one-to-many hierarchy of branches (for example, Main -> Dev1, Main -> Dev2, etc) the one (Main) should be the parent to the many (Dev1, Dev2). If you start with Main -> Dev (Main as a parent to Dev). then adding new Dev branches makes them all siblings under Main. But if you start with Dev -> Main (Dev as a parent to Main) when you add another Dev branch (Main -> Dev2), you end up with a three level hierarchy where Dev is a grandparent to Dev2).

I would suggest using a differnt term (rather than virtual reparenting) in your scenario. You are inverting the hierarchy but you are not reparenting.

In your scheduling question, if you have Parent -> Child and you want to reparent Parent - what will be it's new parent?

Bill Heys
VS ALM Ranger


May 17, 2011 at 9:08 PM

I like your term "inverted hierarchy" more than virtual reparenting.
I agree one-to-many should always flow from parent to children for conceptual consistency.

Current hierarchy: Prod->Main->Int->6+ Dev branches (+ others that are inactive or abandoned for months)
Planned hierarchy: Prod (and future release branches)<-Main->Int->0 to 4(?) short-lived feature branches
          * Short-lived branches should live for up to a few weeks, merge to parent, then be closed (deleted/obsoleted) after merge.

> what will be <Prod>'s new parent?
We're swapping Prod->Main to be Main->Prod. 

In the past we merged all release changes from Main to the current ancestor branch "Prod". Going forward we will create a separate new release branch from Main to avoid risk of merges introducing unexpected differences. We will treat the original Prod branch as our legacy release branch.

We can either reparent Prod to officially make it a child of Main (instead of the parent of Main) or we can leave it with an inverted branch relationship and carefully maintain the Prod branch if we ever need to release a hotfix through the Prod branch.

FYI: We release from 1 to 12 Web services and websites in each release. Per recent related discussion we plan to branch entire Main folder structure then make RC0 through release build(s) for just the related projects from the new release branch.

From related Moving/renaming branches in TFS2010 I've got the answer to my initial question:

>I see no particular reason why you can't logicall invert the relationship between parent and child (Q4).

This conversation also helped me understand that I can logically invert the relationship but we should consider long-term confusion risk. it will be very easy to be confused a few years from now, especially if the Prod branch and Main branch get moved/renamed (which is the bigger part of our plan as discussed here).


I think I have the info I needed for this question. Anyone is welcome to continue posting here if they need any clarification on this discussion. Thanks again for all your posts Bill!

Cheers - ZephanS