Repository folder structure and automated building from that structure

Question

We are upgrading our source control (most likely to Vault) at work and are moving to the branch methodology, and are having some problems with working out the folder structure to use.

We intend to use the Trunk as the development line, and a branch will be a release and bug fixes to that release.

We have come up with two folder structures, and I wanted to know what the advantages and disadvantages of each were:

Projects
  |-> Trunk
    |-> Data Access
    |-> Business
    |-> Desktop
    |-> Website
  |-> Branches
    |-> Branch 01
      |-> Data Access
      |-> Business
      |-> Desktop
      |-> Website

and

Projects
  |-> Data Access
    |-> Trunk
    |-> Branches
      |-> Branch 01
  |-> Business
    |-> Trunk
    |-> Branches
      |-> Branch 01
  |-> Desktop
    |-> Trunk
    |-> Branches
      |-> Branch 01
  |-> Website
    |-> Trunk
    |-> Branches
      |-> Branch 01

If we use a source control block on the build machine (cruisecontrol.net) with the first solution we can say:

<path>$\Projects\trunk\</path>

To build a branch would be fairly similar, but is it possible to pick up the newest branch in the branches folder? otherwise we would have to edit the ccnet config for every release.

If the second methodology were to be used (a lot of people suggest this method) how would the build machine pick up all the relevent projects? somthing like this maybe:

<path>$\Projects\*\trunk\</path>

if some projects have been branched but others have not, how can i make it get the trunk when no branch exists (if this is possible).

would getting all the trunks, followed by overwriting with the branches work? would it just error if it tried to access a non-existant branch?

Answer 1

The first methodology is very reliable. You exactly know what you're shipping (because you have one entry point for each release: either the trunk or a branch/tag).

I see several problems with the second methodology:

1. all projects must branched/tagged at the same time
2. merges must be done for each project individually

Both options are possible, but I consider the 1st one to be the easiest but also safest alternative.

Since the website is most likely independent from the releases (if you release from a branch created in 2007, you don't take the 2007 website, but the 2009).

Project
  |
  +- Trunk

Website
  |
  +- Trunk

Answer 2

In the end i wrote a source control plug-in (using Vault's API) to allow me to specify some extras in the <folder> tag:

<folder>$/branches/%latest%</folder>

will retrieve the latest branch in the branches folder.

Answer 3

I prefer fine-grained, very organized, self contained, structured repositories. There is a diagram illustrating general (ideal) approach of repository maintenance process. For example, my initial structure of repository (every project repository should have) is:

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

Answer 4

I don't guess you open sourced the plugin?