Reputation: 1411
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:
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 :)
Upvotes: 2
Views: 445
Reputation: 10664
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.
Upvotes: 1
Reputation: 95624
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.
Upvotes: 1