source control building a branch

Question

I am currently evaluating different source control solutions for work, and have a few questions about branching.

I have the basic understanding of how to branch, but i am unsure of how our build machine (CruiseControl.net) can get a branch to build it.

We have many projects, which are all relied appon by other projects (there are others to): Utilities > Data Access > Business Logic > Common GUI > ( Website | Desktop clients )

How do we structure the repository (Vault if that makes any difference) so that the build machine is able to:

1. Build the trunk
2. Build the 'latest' branch

A rough folder structure and/or an explanation on how to get from cruisecontrol would be great.

thanks

Edit:

To add some clarity, we intend to use the trunk for development, and then use a branch for each release.

Answer 1

What do you mean by 'latest branch'? Branches should be used for extended devlopment outside of trunk - the trunk should always contain the latest production code.

Each project should have trunk and branches folders:

Project 1
  |-> trunk
  |-> branches
Project 2
  |-> trunk
  |-> branches
    etc.

Your build machine can then checkout any trunk or branch locally to wherever it wants (for your interlinking projects you'll have to set it up so that the relative directory paths work). In pseudoscript:

checkout project1/trunk /builds/project1
build /builds/project1

and

checkout project1/branches/myBranch /builds/project1
build /builds/project1

Answer 2

The solution proposed by Mark works well if the projects have different release cycles (Project 1 has version 1.0 while Project 2 is already at 1.1). If all your projects are inter-dependants, I would start with a simple structure

My Big Project
  | 
  +-- trunk
  |     |
  |     +-- utils
  |     |
  |     +-- data
  |     |
  |     +-- business
  |     |
  |     +-- gui (web)
  |     |
  |     +-- gui (swing)
  | 
  +-- branches
  | 
  +-- tags

That way, you're sure you have branched everything (the whole code) when you do a branch/tag. Otherwise, you always risk to miss one project when tagging.

Your build server would simply check out the trunk (with everything) or one tag/branch (also with everything) and build/install the release.

Once the utils package is stable, you can always "upgrade" it to a sibling project and use Maven/Ivy to manage the dependency.

Answer 3

Just to clarify about how tags and branches would be used in Vladimir's scheme. Let's say that version 1.x of your product is retired, version 2.1 is out in the world, and you're working on version 3.0:

trunk <- you're working on version 3.0 here
 project1
 project2

branches
 ReleaseBranch-1.0
 ReleaseBranch-2.0 <-- fixes to version 2.1 (the current production version) get committed here, then merged into the trunk

tags
 Release-1.0 <-- a copy of the source that was used to build version 1.0
 Release-1.1
 Release-1.2
 Release-2.0
 Release-2.1

In your continuous integration/build server, you're going to need 2 processes:

• one that points to the trunk in your version control system
• one that points to ReleaseBranch-2.0 on your version control system

The book Pragmatic Version Control with Subversion is designed for Subversion, but does go into how to organize a repository as described above.