Subversion and revision engineering - what are the best web resources to read about?

Question

We are migrationg from CVS to SVN and embracing some kind of revision management in order to enforce order to development/testing/release cycle. We are currently testing, developing and releasing on the same code line, we know its a bad practice and we want to make end to it.

What are your experience, know how, suggestions working with source code tree.

We are building small/average (2-5 months) custom projects and we have to give early access to customer for review. Requirement creep is common.

EDIT: please note, i need not only advice on subversion, but more on how whole devel/test/deploy cycle is reflected in trunk/branches/tags/versions etc

Answer 1

• "Branch early, branch often."
• All builds should be completely reproducible without having to pour through logs (consider tagging every build)
• If you use an issue tracker then require all check-ins to have a (valid) issue ID included in the commit message (add a pre-hook to check this).
• Only the build team should be allowed to make production branches (developers should be encouraged to make personal branches for any non-trivial task)
• Build continuously and ensure that everyone is aware that breaking the build is a big deal.
• Read the whole SVN book, then read it again. You need to know this tool backwards and forwards. Hold training sessions for your developers ("how to create a temporary branch for my work", "how to merge", etc).

... There is an lack of good reading on this subject, but if I had to recommend one book to a shop completely green in SCM it would be "The Build Master" by Vincent Maraia. It's very short on details but easy to read and provides a (very very brief) overview of SCM good-ideas that make great sense once you know them but which for some reason so many shops completely lack.

Good luck!

Answer 2

Subversion makes it easier to branch than CVS (in GIT branches are even cheaper). I recommended that you make branches for major revisions, and have a planned merging of the branches back into the trunk. Be vary careful of going long periods of not merging back into the branch, as you it will become more and more difficult the longer you wait.

There are also services out there that provide integrated bug tracking/deployment etc, if you need to get off the ground quickly, and don't want to manage all the server/setup stuff:

• http://beanstalkapp.com/
• http://unfuddle.com/
• http://www.assembla.com/

Some resources:

This particular book answered a lot of the questions I had initially:
http://www.pragprog.com/titles/svn/pragmatic-version-control-using-subversion

Searching Further on stackoverflow:
http://stackoverflow.com/questions/90/good-branchmerge-tutorials-for-tortoise-svn

Cal Henderson (developer at Flickr.com) Presentation at FOWA in Miami that I attended:
http://cdn4.libsyn.com/carsonsystems/Cal_Henderson.mp3

The Free "Bible" of Subversion (Chapter on Merging):
http://svnbook.red-bean.com/en/1.1/ch04.html