Updated [2009/10/19]: TFS Guide (2007) describe Development on trunk as Branch on Release and Maintenance. Here I described the two strategy as one; because in practice I found both of them are indistinguishable.

Development on trunk is arguably the most typical Branch Management techniques adopted by development teams.

The idea is:

1. to have Developers working on the trunk,
2. Every deployment / version release is tagged (labeled) accordingly,
3. When a bug fix needs to be applied to a particular version release
   a branch is made on the corresponding tag (bug fix branch),
   the bug fix then is applied to this new branch.

Most of the Developers' time will be spent working on the trunk. This situation encourages reusability of each others work and minimize the number of merges that needs to be done. The only time when a merge needs to happen is for bug fixes to a version release. Other times, developers are constantly looking at the same version of the code base.

Build Environment Integration

Development on Trunk tend to have a simple build environment. Trunk is often integrated to a Continuous Integration (CI) build process. Depending the frequency of deployments, bug fix branches are normally not integrated into a CI process. All actions that are normally kicked off by the CI process (Regression testing, Unit Testing, Automated UAT, code metrics, etc) will need to be kicked off manually. If deployment happens fairly infrequently (thus, bug fix branch have long lifetime), branches may have its own CI processes.

For projects with linear timeline and effective communications

The pattern is most suitable for product development with a linear timeline; where feature releases are well planned.

When using this technique, it's very critical for the product owner to communicate which feature goes into which version release before the development happens-Each team member needs to know to which version of the codebase they should be working against. In the real world (depending on the product development methodology), this is often hard to do.

Multi-version support

This technique scales to more complicated projects where it is required to support multiple version releases (for e.g. products that are deployed to clients, v1.0 and v2.0 service packs, additional features, etc). This can be done by creating another Trunk.

The decision to create another trunk should not be taken lightly. Working with more than one trunk will hugely over complicate branch management.

It is advisable for this new trunk to not get merged with the origin trunk. Any branch management pattern that you find suitable can be used to manage this new trunk.

Suitable for web projects?

In a small to medium web project, development typically happens in  two different streams: new features and critical bug fixes. Product owners often requires to have the flexibility of deploying between these two streams independently: critical bug fixes needs to be released/deployed anytime as required without interfering with new features development.

Although Development on Trunk pattern support the two streams, it is often at the cost of working without CI in place (remember that many teams who adopt this pattern does not have CI for their bug fix branches). Depending on the release frequency, it maybe costly to add a new CI projects every time a branch is made.

Development on branch / Stemming pattern addresses this issue.