TFS 2013 Source Code Structure and Permissions

Each company will have their own branch structure.  What works for them may not always work for other companies.  Below is an outline of a structure you could certainly adopt.  It is pretty basic and accounts for how we manage our branches and releases.

$/PD
     /TeamX (used interchangeably with a Product)
          /Trunk
          /Branches
          /NonBranchedAssets
     /OrProductX
          /Trunk
          /Branches
          /NonBranchedAssets

We went with one team project and all of our products and teams under it.  Each product and team has it's own area and are represented as folders under the root of the team project.  In the example above the team project is $/PD.  A team or product for example is the Architecture folder.

Under each of these are three base folders.  Each team has this same structure for consistency.  This helps as developers may move around and they won't have to learn a new structure (one big happy team.)

We use the branch structures one of two ways depending on what types of releases we do.  The first scenario, A,  is for some of our longer development cycles.  The other scenario, B,  is for teams who release every iteration.  In some of the images you will note another layer folders called Managed and Unmanaged.  We use this layer to distinguish branches that have a managed environment to go along with them and ones that do not (sandboxes or personal branches).  In my examples I will omit these for simplicity.

Branch Scenario A

In this scenario Trunk is used as the primary development branch for the next release.  Project or Feature branches would branch off of this and end up for example under /Branches/FeatureA.  When complete they would merge back into Trunk and be included in the next release.  Because of the nature of the cycles for this software line at code complete an Integration branch is created for the Release.  It would look like /Branches/Integration/1.0 for the first major release.  This frees up Trunk for work to be merged into it from project or features slated for the next release.  As regression testing completes and the project releases to production a release branch is created for any emergencies that may come up.  It would look like /Branches/Release/1.0.  Any fixes made on the release or integration branch are retrofitted back to Trunk as needed.  The last folder, NonBranchedAssets, is reserved for things the team would like to store in version control but are not part of the built product.

$/PD
     /ProductX
          /Trunk
          /Branches
               /Integration/1.0
               /Release/1.0
          /NonBranchedAssets

Branch Scenario B

This scenario is setup for products on short iteration cycles.  It almost works in reverse and seems to work for those teams.  Here the Trunk represents the latest that is in production or shortly will be.  Development's code-line for the current iteration resides on /Branches/Integration.  If they want to work on cards/features and are not sure it will be completed in that iteration they would create a branch from /Brances/Integration/ to /Branches/FeatureA.  Once FeatureA is DONE it would be integrated back in with the rest of the features being worked on that iteration.  Then when the current iteration comes to an end what has been merged and tested on that branch then gets merged to Trunk.  Some final testing is done on Trunk and that build is deployed to production.  Emergencies would be a branch from Trunk to /Branches/Release/NameOfRelease.  As with the previous scenarios any fixes done for an emergency are retrofitted back to Trunk so as not to create regressions.  An emergency hasn't happened yet but to get the fix I may just have them re-baseline from Trunk to the integration branch.
$/PD
     /ProductZ
          /Trunk
          /Branches
               /Integration
               /Release/ReleaseY
          /NonBranchedAssets

Locking Down Root Structure

To prevent random folders and branches the root structure created is locked down.  This is a deny on various rights to the Contributors group.  Then at the appropriate level this is granted back to the Contributors group (Allow).  The way inheritance and explicit permissions work gives you the flexibility to do this.  

Lock down the team project with a Deny (except for Read).

The folders I don't want people messing with inherit the deny.

Then at the right level grant permissions back with an Allow.  In this case I am showing Trunk.  This would also be done at Branches and NonBranchedAssets folders.

Does this sound like a good plan?