Subversion - should anyone be developing off the trunk?

Question

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 conti

Answer 1

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!

Answer 2

There's an argument to be made that developers should be required to work on trunk.

If you let them branch off, some will be tempted to maintain those branches indefinitely and cross-sync with trunk at regular intervals. This will inevitably lead to complicated merge operations, and these in turn produce bugs.

By forcing everyone onto trunk, they have to keep pretty close to the head, so there will be less risk of bugs being introduced with bad merges. Also, since everyone runs up-to-date code, they're more likely to notice bugs as they creep up, and fixes will get committed faster.

Ofcourse, sometimes a large feature needs to be staged separately, but in those cases a specially approved exception can be made.

Answer 3

It depends entirely on your release schedule. If all the work currently being checked in periodically is intended for release at once, they can all be checked into one area, like the trunk. If there's some work which will be held back while other, as yet unfinished work, has to go out first, the first code to go out could be committed to trunk, and the next code in it's own branch, OR vice versa.

You should find that merging and refreshing branches can be a hassle where things occasionally go wrong. So naturally trying to minimize that would make sense. The overall idea of source control is that everyone can work in one place.

Often when you get larger teams, the release schedule is organized by sub-teams and their projects and these have their own branches.

Answer 4

I think if you are agile and release in small increments within a few weeks, you should develop in trunk. This way, you have the latest in trunk, it gets built constantly, may be it gets broken, but would get fixed soon and when you are ready to release, tag it and release it. This way, there is no headache of merging from branches too.

I think I'd also like to add that if you are developing in branches, you can't be agile. Developing in branches works only in waterfall.

Answer 5

I think it really depends on the scale of your operation. Up to maybe 5-10 developers everyone committing to trunk should really be OK. But of course everyone should keep in mind that the trunk needs to always be compileable. If they're working on major changes that won't compile for a while, then they should move off to a branch.

Answer 6

I think the tools you use are a big factor here as well.

• If you are using Subversion, unstable trunk will probably work better for you.
• If you are using GIT, stable trunk will be much easier than Subversion.