TFS -- Sustainability of Cascading Branches

Branching guidance usually describes an immortal "Main" branch, with features branched from Main, and merged back to Main, and Releases branched from Main, with further branches of a Release as necessary for Service Packs, RTMs, etc. The guidance regarding Main is often simplified to "no trash in Main."

I'm working with a group that releases regularly (as often as monthly) and serially. To them it seems unnecessary to ever return work to the Main branch. They use TFS 2010--diagramatically their branching structure looks like this:

Daily builds on a branch are made; eventually the branch goes to production. Any hotfixes to a branch are applied directly to that branch, and optionally merged forward to any future in-flight branches.

This group's branching strategy has been described perjoratively as the "Cascading Branches Antipattern." But is it really, given that these branches release to production, and then (usually) have a fairly short time to live?

Is this practice of cascading branches in TFS sustainable over the long term. If not, what are the limits, and when (after how many branches) might they be reached?

Is there any reason to NOT "destroy" Main, R1, R2 (etc.) eventually, or is there a "gotcha" that will prevent destroying and reclamation of space开发者_如何学C on the SQL server that is hosting the source code repository?

---

Cascading branches can work. I also can't think of any technical reason why destroying very old (preferrably archived) branches would impact the newer cascaded branches. Here are some issues to consider:

1. Developers have to map a new branch to their workspace after every release.
2. Developers have to manually move any work to a new branch if they weren't able to check it in before release (vs. just checking in to the same working Dev or Main branch after release.)
3. If you have one or more developers working in a child branch of Rn and a decision is made to move their work to Rn+1 then a baseless merge will be required to avoid checking into the original parent Rn branch.
4. MAKE SURE YOU SECURELY LOCK EACH BRANCH after release. All those branches will increase risk of a developer accidentally checking in a change to a released branch.
5. You need to adjust build definitions and any other path-specific artifacts after each cascade. If all development just works out of Dev (or Main) then the primary workspace and related build/project artifacts remain the same over time.
6. How do you work on a parallel features in isolation when you don't know which feature(s) will ship in Rn? (If you have a main branch the you can have multiple child feature dev branches from Main, then merge a feature branch only when it is stable and ready to merged to ship in the next release.)

I believe Jeff Levinson did a presentation that described branching evolution starting with single branch, then cascading branch, then Main+Release and a couple variations (while describing pros and cons of each). Check out Branching and Merging Practices - Jeff Levinson (Teched 2010 Video) (or related Branching & Merging PPT).

Enjoy! -Zephan