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

Reparenting to insert a Service Pack branch

May 5, 2011 at 3:07 PM

In a test instance I was able to convert a "Basic Branch Plan" to a "Standard Branch Plan" by inserting the Service Pack branch. I did some reparenting and a baseless merge to make it happen. It didn't seem difficult, though it had many steps. I was thinking about following this pattern. I like this way because I don't have to create a Service Pack branch until the moment I actually need one. In our case, we may never have a SP or we may create the SP to a release a year after the fact. We just don't know up front.

Is it safe to insert a branch, do a lot of reparenting and baseless merges, to get my Branch Hierarchy like I want it after the need arises? Or is it better to create the extra branches just in case we might use them? What do you think?

Thank you!


May 5, 2011 at 3:30 PM

Here is how I "inserted" an SP branch. Assume I have a Main that is a parent of 1.00. Main --> 1.00

  1. Branch from 1.00 and create a 1.01.
    1. Main --> 1.00 --> 1.01
  2. Baseless merge 1.01 to Main 
    1. tf merge /baseless /discard "$/Test/Release/1.01" "$/Test/Main"
  3. Reparent 1.01 to Main
    1. Main --> 1.01
    2. Main --> 1.00
  4. Reparent 1.00 to 1.01
    1. Main --> 1.01 --> 1.00

That's it! It seems to work and is easy enough to feel "safe", but am I going to cause myself problems down the road if I do this a lot?

May 5, 2011 at 4:00 PM

I did notice that the 1.00 branch still has Main as a possible merge target branch. I don't know how to get that out of the Merge Wizard Target branch dropdown.

May 5, 2011 at 4:52 PM

I will respond shortly. I am about to post a blog or two to provide context to my response.

Bill Heys
VS ALM Ranger

May 5, 2011 at 8:49 PM

I have just posted a blog: In it I discuss the real overhead of creating a branch and not making changes to any files in the branch. You might want to read this for some context.

I would prefer to create the recommended branch structure at the *time of release*, rather than creating a servicing branch at the time of need and then trying to insert this new branch between two existing branches.

Rather than branch Main -> Release and then some time later branch Release to Servicing, do a baseless merge between Main and Servicing and then reparent Servicing to Main and Release to Servicing, I would much prefer to branch Main to Servicing and Servicing to Release at the time of release. Even if I don't make changes post-release, the incremental cost of having this branch in place in the event I need it seems better than not having the branch structure I need when I want to do a hot fix or service pack.

You are correct that when you do the baseless merge and reparenting, you will now see multiple merge targets for some branches. There is no way to remove these from the merge wizard target branch dropdown. It may prove confusing and error prone as a result.

Bill Heys
VS ALM Ranger

May 5, 2011 at 10:25 PM

Bill, thank you for your reply and your time. Much appreciated!

May 10, 2011 at 10:19 PM

I've been thinking about this for a bit now. I'm not concerned with the size that branches take up.

It seems to me that the ultimate path of fixes mirrored in branches would be ideal. It would look something like 1.0 --> 1.1 --> 1.2 --> main. Simple to look at and easy to follow when merging changes. If I can achieve that by reparenting branches, is there a reason not to do it that way?

I feel as though I am oversimplifying and probably missing something. I also am not sure if doing a lot of "reparenting" with TFS will muck up the inner workings of TFS somehow.

May 11, 2011 at 12:55 AM

I cannot asset that doing  a lot of branch reparenting will NOT muck up the inner workings of TFS somehow. I can tell you that there is no way to remove the extra merge relationship from the target branch dropdown. I can also tell you that TFS has plenty of issues dealing with renaming files (not the same as reparenting), particularly when files were renamed in TFS 2008 prior to upgrading to TFS 2010. If any one issue keeps popping up on my radar it is the challenge TFS has with renaming files, and / or deleting a file and adding a different file with the same name.

I know of no specific issue with *excessive* branch reparenting. But then again, I was not aware of any problems with file renaming in TFS 2008 until they changed to slot-mode identification of files.

I work with many companies with branching requirements similar to yours. None have found it preferrable to do reparenting as a routine process. I would personaly prefer to proactively create an empty branch structure in the correct hierarchy over routinely inserting brancthes through reparenting.

This is my preference, and as I said ealier, I know of no particular issues but cannot assert there will never be an issue. Since reparenting relies on baseless merges and baseless merges in themselves are to be discourgaed (deletes are not handled as you would expect, etc), I would not go this route.

Good luck!

Bill Heys
VS ALM Ranger

May 11, 2011 at 2:49 PM

Thank you again, Bill. I definitely take your advice to heart. I'm not convinced my idea is good either. ;-) I'll play around with it some more on our test instance because I'm interested. However, I'm not comfortable with it in production. I'll follow the guidance. There is definitely something to be said about tried and true solutions....they've been tried...and they work. ;-)

May 11, 2011 at 3:56 PM

I wrote another blog for a customer with a slightly different problem. But it may provide some insight. (

Rather than having a separate branch for every hotfix in an inverted hierarchy as above (1.0 -> 1.1 -> 1.2 -> Main), I recommend a combination of branching and labeling to allow this customer to make a hotfix to any version of his software EVER released.

Bill Heys
VS ALM Ranger