Does this sound like a good idea? ( svn / version control / webdev / deployment )

Question

I've recently gotten charged with designing and implementing a source code version control, testing, and deployment scheme at the company I work.

Personally I've worked with Subversion for a few years on my own projects. But I've never dealt with it at this big scale. Hence I thought I'd ask here if anyone has any comments or suggestions about the following setup I've deviced:

• Trunk is used as the main development tree, as it should be
• Remote servers (testing and production) check out code from the SVN repo.
  • Testing servers check out trunk.
  • Production servers checkout the "production" branch.
• Once trunk is deemed ready for production, it's merged into two branches, "stable", and "production".
• The stable branch is a stepping stone to the production branch. If bugs are found once the new code goes live on the production server, the stable branch is used for fixing the bugs, and also testing the bug fixes.
• Once fixed, changes are merged into the production branch, and also back into trunk where development has kept on going like normal adding new features and whatever independently of any bug fixes that were needed.

This way, development doesn't have to halt on trunk whenever there's a production release, as bug fixes aren't dependent on trunk. Also, there's always a "read-only" branch where the latest stable and most-bug free code is available, even in the middle of heavy bug fixing.

If anybody has any suggestions, comments, or otherwise, I'd greatly appreciate it :)

Answer 1

Check out Continuous Integration and Cruise Control/CruiseControl.NET. You can set up "projects" under CC to check out automatically (every n min) or on demand. For the trunk you'd want to automate it, and for the stable branch you'd make it on demand.

Once the project gets bigger and trunk becomes something to protect, you would want to occasionally set up a TRY branch to do major changes or cutting edge/experiment/future development.

Answer 2

I'd look at the Pragmatic Version Control using Subversion book. They lay out a really good structure for organizing both the repository itself as well as for handing tagging, branching, and the trunk with regard to releases, bug fixes, new features, experiments, etc. They've got a naming convention for all of that as well as "recipes" for the SVN commands to take care of each.

It's a fairly quick read and they've done much of the thinking and heavy lifting for you, including the stuff you haven't thought of yet.