Hi, What are the pro's and con's to developing in:
In what situations are these useful and what type of projects do they suit?
Many thanks.
Please read the Tags and Branches section in the free Subverson book. This is one of the best and simplest explanations to be found anywhere.
For a comprehensive discussion of branching and release strategy, see the TFS 2008 Branching Guide 2.0
Basically you'd normally have three lines in your version control, two development and one informational. That is the Trunk, the Branches and the Tags.
The trunk is the main line of development and new features are generally developed in here. When you have reached a point when you want to make a release, you create a release branch.
Once a release branch is created, all work towards that release is done on the branch (bugfixes, last-minute-features etc) and the release is eventually cut from that branch. In the meanwhile, development can continue on the trunk, allowing some of your team to work towards large features for a later release. Changes made on the branch should be merged back into the trunk to ensure bugfixes in the branch are also applied to the trunk.
Tags are a location to store snapshots of the code at important points. We tend to use them for marking points where we create branches and where we cut releases.
A common way of managing this is to use the branch for a particular version "line". So you would branch from the trunk for release version 1.1, and when it is ready, cut a release as version 1.1.0. Now you can continue working towards 1.2 on the trunk, whilst being able to react to bug reports and feature requests independantly on 1.1
I'm currently using this for one project that is at release 0.1.0. I'm currently working towards 0.2 with a big, complicated feature that will take some time to implement. In the meantime i'm getting bug reports and small feature requests for the live 0.1 version. I simply switch to that line of code, make the fix/addition, release a new version (in this case 0.1.1) and then merge the changes back into the trunk where I can continue working.
EDIT: I forgot to mention development branches, the other primary use of branches. Sometimes it's useful to have a branch of the source code set aside where potentially catastrophic changes wont affect the working build that others are working on. That's where a development branch comes in. It's usually only used when you're researching something you've never done before, doing major (MAJOR) refactoring or prototyping something new and complicated. Basically any time your commits are going to make it really hard for the rest of the team to keep up the release and maintenance schedule.
We generally use the trunk for most development and create a release branch when we start working on features that are not for the next release. We typically use feature or experimental branches for things we're testing out but are not definitely in the next release. Having too many branches and managing merging patches across can make things more complicated, so if there is no real need to use branches, then don't (but don't avoid them if you really have a need).
One factor for us is we use externals for modules shared across projects. This was a huge problem with branching and tagging when we first started out since tags/branches don't affect externals (they still point to the latest unless you specifically pin them down to a revision or change them to point to a branched external or whatever). We refactored a lot of our code to get all projects down to one external which has made branching/tagging easier.