At the outset, I should say that we’re a contract development company working basically as an outsourced IT department producing custom software, with a few components that are reused between solutions which are run a little more like commercial software. Because the projects are relatively small, it’s rare to have multiple developers working in the same codebase concurrently, and even then generally only for the first release or major additions of new features.
We operate like this:
All new development work is done in trunk. Each release is labelled.
On the rare occasions that a customer needs a patch to a previous version that has to happen out-of-stream, i.e. while developing the next major release, a bug is discovered in the previous release that can’t wait, we branch at the label and make the fix in the branch. The check-in MUST only contain that one fix - keeping the check-ins small keeps the merge small. The fix is then merged into the trunk.
On even rarer occasions we’ve already found and fixed the bug in developing the new release, but the customer then asks for the fix earlier. Then we do the merge the other way, but it’s less likely that the fix was isolated, so it may need the fix to be implemented manually.
If you’re unlucky the bug is in an area that has been heavily revised so you have to work out whether the bug even occurs in the new code and if so, how to fix it.
Anything truly experimental is generally not checked in until validated. If it looks like it’s going to need to be backed up - it covers more than a few days of work - or if the experimental work requires more than one developer, then we would use another branch for that, even if no development were happening in trunk. At some point the experiment will either get accepted and merged back into trunk, or get thrown away.
In a few cases we’ve sold very similar systems to customers, where we’ve developed it a little more proactively, and these are also organised as branches in case a fix is required in common code. Generally I’d prefer to make the common code a project in itself, with per-customer customisations, but that wasn’t possible in the timescales agreed.
Tools: SourceGear Vault 3.1 with the companion SourceGear DiffMerge tool.