Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

Last Time… we looked at installing and setting up VisualSVN Server to be our Source Code Management (SCM) system. With our SCM system all set up, now we need to take a look at how to best take advantage of its features. We’ll look at common folder structures for code repositories and what they folder do/mean.

Just about anyone who has used some sort of code repository has probably seen this structure:


This is a very common pattern because it highlights the three main things you want your repository to keep track of for you: your trunk (the main line of development or your current branch), tags (each “marked” version of your code) and branches (each live of development that detours from the main, like prototypes, refactors, etc). Branches help you to to work on the code while keeping the trunk “deployable” (or close to) at all times.

There are many different theories/practices surrounding branching and merging (forking off the main line and developing, and then merging the developed branch back to the main). I tend not to branch unless I am doing a spike story (an experiment or proof of concept) or if I am squashing a major bug that might cause some significant design changes.

You may ask yourself, “How did get here?” (But I digress…) What you may really ask is: Where do these folders go? And, just like any important computing question, the answer is: It depends.

It depends on your business and development structure, and how your team organizes its code, but my guideline is: for every solution-level effort (where a Visual Studio solution is being created) I follow this structure. So in my personal code repo on Google code, you’ll find:


These are three of the projects out there. So each undertaking gets it’s own set of the three major folders, and under each is the arrangement for the project itself. Generally, inside of the trunk folder I have several more folders. They are a good way to arrange everything I might need for a solution. Like Below:


The Build folder is used for my build artifacts (we’ll discuss making a build file in the next installment). When the build runs, it will put output files in this folder. The db is where I store my DDL scripts for creating my database (we’ll get into builds creating databases in the next installment or two). The docs folder holds any documentation the project might need (thanks captain obvious). The lib folder holds all of my project references, the dlls my program or it’s helpers need to reference to do their job. For instance, Structure Map, NHibernate, MSpec, etc. The specs folder contains all of my Behaviour-Driven, Executable Specifications. and finally my src folder holds the source code for my program. You’ll also notice that my *.build file and my batch file for running (just to make it one click run) are also here. This is mainly for ease of use, so that the build file has access to all the folders containing the code it is going to build.

Again, there are probably many different folder structures being used all over, but this is the structure I use currently because it serves my needs and makes everything easy to get to. I am never afraid to change it up to accommodate a special requirement or problem. The trick, I think, is to be pragmatic about what you do. Understand that if you start with only a few folders, and it starts to become unruly, you can break things down more, but starting off with a bajillion folders and trying to combine things later can be a bit more tricky.

Well that’s a general breakdown of the source code folder structure for the project we’ll be building our dev shop around. I cannot stress enough that these are my opinions of how I am currently doing things. I may change something if I find it is causing friction. Just recently, in fact, I moved my specs folder up to the same level as the src folder and the lib folder. This is something I saw done in the Sharp Architecture project and I liked it. It keeps my specs back away from my code physically on my hard drive and with projects in a solution, still allows them to look as if they’re side by side (it will become clearer later why this is important).

In the next installment, we’ll create a base project. We’ll talk about project structure, and answer that age old question, “How many projects should you have in your solution?”

Stay tuned for part 4!

Posted on Tuesday, September 8, 2009 11:26 PM | Back to top

Comments on this post: Let’s Build a Dev Shop (Part 3 of n)

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: