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.