The repository layout

Team Foundation Server provides the ultimate flexibility in terms of how you arrange our data. Because it simply versions directories and files, and because it describes no particular meaning to any of those objects, you may arrange the data in your repository in any way that we choose. Unfortunately, this flexibility also means that it’s easy to find yourself “lost without a roadmap” as you attempt to navigate different Team Foundation Server project repositories that may carry completely different and unpredictable arrangements of the data within them.

To counteract this confusion, you can using a repository layout convention (established long ago) in which a handful of strategically named Team Foundation Server repository directories convey valuable meaning about the data they hold. Most projects have a recognizable “main line”, or trunk, of development; some branches, which are divergent copies of development lines. So we first recommend that each project have a recognizable project root in the repository, a directory under which all of the versioned information for that project—and only that project—lives. Secondly, I suggest that each project root contain a trunk subdirectory for the main development line, a branches subdirectory in which specific branches (or collections of branches) will be created.

In our case branches will contain the developers name followed by the TFS task item they are working on.  This makes it very clear at any time who and what was required.

Trunk would be the main body of development, originating from the start of the project until the present.

Branches will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.

Shelve Pending Changes stores your code changes on the server but doesn’t commit them to the branch. Here are some reasons for using it:

  1. To save changes but undo locally when I’m not ready to commit changes but I need to make an emergency bug fix on the same branch.
  2. To store code for code reviews prior to committing. Other people can check out or view your shelved changes.
  3. To store changes that are ready for committing when the changes aren’t approved yet.

One thing to know about shelving changes: When you unshelve, you get the file as-is. If someone else has modified the file after your shelve, no merge happens. So I don’t recommend shelving changes long-term.

Here are some examples of the structure


$abc\src\csp\branches\David Jason\3243

$abc\src\csp\branches\David Jason\3122

The repository main root has the following structure and shortened names, this is because Visual Studio has a 260 character name length restriction.

src           Source Code

dep         Deployments

If you are making a large Branch it is recommended that you plan you merge back to your trunk when you branch, as the longer period of time the Branch is separated from the Trunk the more work is going to be required to merge the two back together.  As a rule of thumb one week is acceptable where as one month is much too long and will result in a lot of merge conflicts.  If the branch is out of the main trunk for more than a month then before the code is merged back to the main trunk full testing of the source will be required, both unit tests and system integration testing which will require to be signed off by the test team that it passes full regression testing before the code is merged back to the main trunk.

With larger branches they can have their own trunk and branches while they are being worked on.  If a sub trunk has been created then it is best practice to make sure a build is triggered on all checkins to this trunk to ensure that the code can be build successfully on the build server.  It is important that the above paragraph on merging back is adhered to.

[1] This is the your project level for the Repository; you will find many others as these are historic and should only be used for reference.