Subversion - should anyone be developing off the trunk?
When using Subversion, should developers be working off the trunk or should the trunk be only used for merges from each individual developer's branch and watched by a continuous integration service?
There are two basic strategies:
- unstable trunk - the trunk always contains the latest code, branches are made to do releases
- stable trunk - code is developed in branches and checked into the trunk only when fully tested and releases are performed from the trunk
Which you use is to certain extent a matter of personal preference. But alongside either of these, individual developers should be using branches for their own experimental developments.
So as usual, no definite answer!
Depends on how extensive the changes are. A general good practice is that trunk should always be compilable, but that doesn't necessarily mean developers can't work on the trunk for small changes/bugfixes - after all, that's one of the reasons for having a working copy; you can make sure something compiles before committing it.
Larger changes or feature additions should almost always be pulled off into branch until they're ready for integration so as not to interfere with other development.
There are a number of methods for working with version control systems for parallel development. There's nothing wrong with the one that you suggest above - but there are advantages and disadvantages attached to each. I've worked in both ways.
Developing off trunk and cutting release branches is fine, but if you need to perform an emergency production release you end up having to patch the release branch and releasing that again - means building a branch in your CI system.
Working in branches and preserving the main trunk (monitoring with a continuous integration system) is also fine, but can lead to conflict issues with developers in multiple branches making changes.
Take a look at the following site also:
http://www.cmcrossroads.com/bradapp/acme/branching/
It discusses a number of branching patterns for parallel development including:
- S1. Mainline
- S2. Parallel Maintenance/Development
- S3. Overlapping Releases
- S4. Docking Line
- S5. Staged Integration Lines
- S6. Change Propagation Queues
- S7. Third Party Codeline
- S8. Inside/Outside Lines