We have spent a lot of time lately talking to clients about how to structure their source control system. There are lots of documented branching strategies (we can talk about those some other time), but not a lot of discussion on how to structure folders, particularly how they relate to branches. A couple of options are described below. Some of the terminologies are TFS-oriented, but the concepts can apply to any source control system.

Folder Structures

 

In addition to branching, the team needs to decide on the physical folder structure. The two most common pivot points for folders are:

  • Arrange according to release first
  • Arrange according to branch purpose first

 

By Release

 

Arranging by release would yield a structure similar to the following (b = branch, f = folder):

$/Project

Product A (f)

6.4.0.0 (f)

Service (b)

Release (b)

7.0.0.0 (f)

Service (b)

Release (b)

Current (f)

Dev (b)

Main (b)

Feature (f)

Feature branch (b)

Product B (f)

:

 

Pros:

  • Easy to find release branches
  • If a dev is not working on a particular release, cloak the whole folder
  • Reflects the branch structure a little more intuitively

Cons:

  • Release isn’t grabbed very often, so have to cloak a bunch of release branches
  • Feature branches, if used, get quite deep down the hierarchy

 

NOTE: The “Current” folder is not strictly necessary, but keeps consistency with folder reasons.

 

By Purpose

 

Arranging by purpose would yield a structure similar to the following (b = branch, f = folder):

$/Project

Product A (f)

Release (f)

6.4.0.0 Release (b)

7.0.0.0 Release (b)

Service (f)

6.4.0.0 Service (b)

7.0.0.0 Service (b)

Dev (b)

Main (b)

Feature (f)

Feature branch (b)

 

Pros:

  • Most of the time, a dev will never touch the “Release” folder, so can cloak the whole thing once
  • The second level of the tree is all consistent by purpose

Cons:

  • Will still likely have to cloak individual service branches
  • Does not reflect the branch structure as accurately

 

 

Folder Structure Summary

 

Bottom line: there is no right answer for folder structure. Consider what works best for your team.

 

Notes:

  • Ignore the “Product A” level of the tree if you only have one product in source
  • Also, consider folder structure under branches like Dev and Main. One example is:

Build

Doc

Src

Project

Exe

Lib

UnitTest

:

Test

Tools

  • Keep unit tests alongside the projects. They should all build together, and a developer should never cloak the test directory. Keeping them in a different place in a tree is not recommended, making the tests harder to find and less likely to be run and updated.