Using Subversion

As far as source control is concerned I've decided to go for Subversion (SVN) using the TortoiseSVN client. I've been using this combination for a while now and through my experiences and articles I have read, I've come to believe it is one of the best source control systems out there despite it's freeness. I believe that commercial system offer more in terms of integrating source control with other systems such as the IDE, an issue tracking system, ect. etc., but no more in terms of a source control system. It's easy to use but behind the childlike interface of Tortoise is the power of a source control system that successes CVS which has been used in the majority of open source projects out there and as such is an indication of its ability to enable smooth collaboration between a development team. This is in my mind the primary goal of such a system.

The structure of the repository I'm going for is as follows:

• Trunk
  • Tools
  • Library
  • Source
    
• Tags
  • Builds
  • Releases
  • Other
    
• Branches
  • Tasks
  • Personal
  • Other

Each of these folders are described bellow:

Trunk

This is where all artefacts that are related to the project go.

Tools

Tools used in the build process of the project are stored here. Examples may include assembly merging tools (ILMerge), obfuscation tools, compilers, unit testing tools, etc.

Library

All externally compiled assemblies should be placed in an appropriate folder inside the library folder.
Additionally, svn-external projects/ libraries should be placed her. However, care should be taken with respect to Tags. If the SVN-Externs points to the head of a Trunk, then when Tagging, no information is stored with respect to which revision of the trunk was in use at the time. For this reason, when it becomes important for tags to be exact (for example for the purpose of recreating a build), svn-externs should be made to point to either a Tag or a specific revision. When this is the case, care should be taken to update this when changes are made to the external repository.

Source

All artefacts that are compiled or in some way make up the release should be placed here. Solution projects should be nested inside the solution folder. Each business project should ideally be made up of only one solution file. External assemblies/ Libraries/ Library projects should be referenced from the Library Folder. Setup projects should be in a folder of their own and the source files for the setup project should be taken from a source folder insider the setup project folder. Finally the source route should contain a batch file of something of that sort that generates a release. The hows and whys of this will be covered in a released post.
An example structure for the source folder is as follows:

• Source
  • Solution
    • projectA
    • projectB
  • SetupProject
    • SourceFiles
    • SupportFiles
  • build.bat

Tags

This is where Tags (snapshots of) the Trunk are kept to represent the state of the trunk at a particular moment of interest. Care should be taken not to commit changes made accidentally (and changes should not be made purposefully) to Tags. (Because SVN treats Tags and Branches in the same way, it allows this).

Builds

This is where tags of builds are kept. These are generally automatically created by the CI server.

Releases

This is where tags of releases (i.e. versions of the code that have been assigned a specific release version and have been sent for testing of to the client) are kept.

Other

This is where others tags are kept.

Branches

Branches are for copies of the trunk made in order to fulfil a particular task. Branches assist developers in that they allow them to commit unstable and untested code that should not under normal circumstances be committed to the trunk. It is often necessary to do this because a logical task may span over a few days in which case the developer will still want to keep his code in the safety of the repository.
The general purpose of branching is to eventually merge changes back into the trunk. In Subversion, this is often a delicate operation - not as straight forward as one would hope. So far I've found a couple of things that can cause issues when merging. These are generally related to renaming and moving files/ folder on the branch. (Maybe even on the trunk, though I haven't tried this). Thus my recommendation is to avoid these operations on branches.

Tasks

This folder contains branches that are related to a particular task (e.g. 'issue 345' or 'Adding paging to SearchLists'.

Personal

This folders contain branches that are for personal use/experimentation by developers

Other

This folder contains other branches.