Project Layout Revisited

As has happened with me previously, getting a topic off my mind by writing about it or expelling it in some other way has left my brain free to proceed further with the topic. This happened today with the topic of my previous post on laying out a project folder structure on the filesystem and in a version control program.

I expressed dissatisfaction with the typical branches, tags, trunk structure of a subversion project as I felt it did not allow for independent version control of individual items generated during development. Items such as the documentation and test rigs, I stated, could only be version controlled along with everything else in the product.

The solution I presented was to have separate projects for each of the configuration items of a product: requirements, design, implementation, documentation, test, and release. Each of these would have their own branches, tags, trunk.

Today I realised that this solution was borne out of a conceptual block with the way subversion is used, particularly in the creation of tags and branches. My default process for creating a tag, for example, is to go to the root of the trunk folder and perform an svn copy to a new tag folder in the root area of the tags folder. Doing this copies the contents of everything in trunk, which I didn't want to do.

What didn't occur to me before today was that it is completely permissible to do an svn copy from a subdirectory in the trunk to a subdirectory in tags or branches. This would effectively tag or branch a particular folder of a subversion project. If those folders are the requirements, design, implementation, documentation, test, and release areas I expatiated previously, then I get the same result as the separate project per configuration item.

This alternate layout looks like this:

product_name
- branches
 - requirements
   - b1
   - b2
   - ...
 - design
   - d1
   - ...
 - implementation
   - ...
 - documentation
   - ...
 - test
   - ...
 - release
   - ...
- tags
 - requirements
   - tag1
   - tag2
   - ...
 - design
 - ...
- trunk
 - requirements
 - design
 - implementation
 - documentation
 - test
 - release

As with everything, there would be advantages and disadvantages with this layout and the layout presented in my previous post. The big advantage for me with the structure above is that I can just check out product_name/trunk and have everything at my fingertips. I just need to remember to define the destination correctly when performing an svn copy.

An advantage with the layout presented in my previous post is that it allows better separation of concerns. This is particularly relevant in large teams where certain people will only be involved with requirements and a completely different set of people may be involved in the release.

For myself, basically a sole-developer, to get everything with the per project structure means checking out six trunks or checking out at the root and getting all branches, tags, and trunks for all configuration items.

I'll play with this new structure soon and see if it is effective in practice. Now that I have this extra information off my mind, I wonder what my brain will tell me tomorrow.