-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Assuming most of you read the previous mails, i will skip citations ;).
A point that is totally ignored is that the size of the project matters. I worked on several small to big-sized projects with svn. With small projects, it is possible to have development and production on trunk and skip the hassle of branching/merging. On medium sized, it is advisable to have every bigger enhancement happening in a branch, while still having the live server working on trunk. The solution for our biggest projects was to use tags for live versions. (Tags are as cheap in svn) This ensures that no accidential updates happen. Updates on a live server are done by 'svn switch'. Usually, there is a beta server set up using the live database where tags a tested in between.
The point of 'only working things on trunk': sure, you should try not to commit totally broken code. But things that are not finished or contain minor bugs that annoy but don't break are okay - it is the active development branch after all. If you trust your ongoing development to go all well, you can use it as _the_ branch, but thats not always the best way. In an environment with multiple programmers, commiting everything is live-saving. 'Hey, xyz is ill today, do you have access to his working copy? This stuff has to be done today!' is a problem that does not need to be occur.
Greetings Florian