Team Foundation Server Development Structure

Question

I'm a part of a small development team who are in the process of moving from Visual Source Safe to TFS2010.

I've been reading about TFS structure and came across a very good question.

One thing mentioned in the above link which I'm not sure about is the Development structure:

- Development/
      - Trunk/
          - Source/
          - etc/
      - Branches/
          - Source/
          - etc/

I don't really understand the need for the Trunk and Branches as separate children containers to Development . How I'm reading this structure is that Trunk would branch from Integration (or Main if you use MS terminology) and Branches would then branch from Trunk (ie Trunk is the parent to multiple Branches ).

If this is the case, I don't understand the advantage of the extra layer in the hierarchy. What seems logical to me (remembering that I've been learning this stuff for about a day) is that if you want multiple development branches, to have each development branch as a child of the Development container:

- Development/
      - DevBranchOne/
          - Source/
          - etc/
      - DevBranchTwo/
          - Source/
          - etc/

In the above structure (where DevBranchOne and DevBranchTwo are replaced with meaningful names), development branches are siblings and all branching from Integration (or Main ). Given the above, my questions are:

1. Is my understanding of the intended use of the Trunk in Development correct?
2. If the answer to my first question is yes, what is the advantage of implementing such a hierarchy in Development ?
3. Is the use of Trunk simply something that has been carried over from SVN (with which I have no experience)?

Answer 1

I agree, in the post you linked to it appears he has 2 "trunks", the Development\Trunk and Integration which is just another name for trunk in his context it appears.

Depending on your branching strategy you usually only want to have one "trunk" (or integration branch).

However, there are some scenarios where you might want multiple integration branches, such as if you are doing something like branch by feature, but you also have a concept of feature groups where the various feature branches need to be integrated together into the feature group, before being integrated into the subsystem's integration branch, which then will later integrate into the products main integration branch (aka trunk).

However, most branching strategies only require a single integration branch.

Answer 2

I would not necessarily recommend using this other question as a model. It sounds like they're rolling up multiple feature branches into an integration branch ("Trunk") and then further integrating into yet another integration branch ("Integration"). This seems like a branching system meant to fit their existing workflow - while there's certainly nothing wrong with this system, it doesn't fit into my workflow, and you'd have to change yours to adopt.

In other words, you'd probably already know if you wanted a branch system like what's described in that question. Your description of what you're anticipating is probably a good starting point: multiple development branches and a single trunk (or main, or whatever you want to call it) branch.

If you haven't yet, be sure to check out the TFS branching best practices from the Visual Studio ALM Rangers.