Your branching strategy looks really good to me. I have done the same strategy in the past and it works fine. Draw it up on a whiteboard and get all your devs to understand it so that people do the right work in the right branch. Teach and explain to everyone the switch command and get everyone to doublecheck the branch that they are working on. (Or alternatively just check out the entire repo... depending on your code size :) Remember... svn revert is your best friend!
Personally I prefer one person to be the "merge/branch" person (with a few backup people as reserves) to ensure that everything is kept under control and consistent. Let that person become your SVN guru and you'll be away.
A few other helpful hints:
- Encourage frequent SVN updates and SVN commits. Every day is preferable.
- Cross branch merges should also be done every day, or alternatively whenever a bug is fixed. Do them early and do them often! (you'll get good at it real quick).
- Get a good diff tool - beyondcompare is ace. The standard tortoiseSVN one... not too good.
- Don't check in stuff that changes upon compilation (like your output directory)
- Try to clean up your repo before you start branching (get rid of files that don't need to be under version control - things like external libraries etc). The smaller your repo, the better
- Changes to your Production branch and QA branches should be as small and short as possible - don't start refactoring code there, just fix the bug.
- Make sure you branch from the top level of your solution - and if you have a DB I hope you've scripted all of your DB stuff (like stored procs or triggers)
Also tell people not to move folders around unless it's strictly necessary. This will make your merging much easier :) (Don't do what I did, launch upon a massive directory restructure halfway through a huge change to trunk which screwed up all of our merges... I was pretty popular after that).
For a team of 3-4 devs, you're proposing WAY too many branches.
Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost.
Keep in mind that the only real benefit to a branch is code isolation. That means you need a concrete reason to want to have the code isolated.
Having a separate release branch for every sprint is insane. Why do you need the code from one sprint isolated from the code for the next? Why not just have a single stable release branch that gets carried forward with each sprint?
If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.
Almost any non-trivial new feature is going to take at least a week in real time after you account for development, developer testing, daily interruptions and other activities, etc.
Also, what's a "regular merge"? Daily? Weekly? Every merge you do takes time - you need to make sure the target merge branch builds & runs after your changes. On a small team, frequent merging is a lot of overhead.
We have a team of 4 developers working on a 1+ million line codebase and this is how we operate:
- Main branch where all development is done
- One branch per major release (done about once per year)
The one major rule is: don't check in code that doesn't build.
That's it. Simple, easy to understand, gets the isolation we need (at any time we can create a release build for any version).
The upsides to having all development work done on one branch:
- Developers are always in-sync with each other. No painful merges because two developers were off on their own branches for weeks creating incompatible changes.
- Broken builds are found on the same day. We have a nightly build that runs the latest code on main. If someone does check in code that doesn't build for some reason, we will know right away.
- With everyone always working on the same code, in increases the chances of a bug being found sooner rather than later.
- No merge overhead other than targeted fixes to release branches. On a small team, this is the big one.
Best Answer
Sounds like 'scenario 2: branch for release" as described by Microsoft's guides.
Its probably the most commonly used branching strategy when using TFS, you have a Main branch from which you make a Dev branch for development, when you're read to merge back, you merge onto Main, perform some testing and then either release from the Main branch, or more commonly, take the Main onto a Release branch so you can make changes to an individual release without having to worry about further updates that have been merged onto Main getting in the way.
Some people never make bug fixes directly on the production branch, they branch from it, make the bug fixes and then merge them back when they've been tested and verified. It makes things easier if you decide not to go with the bug fixes, or have to revert them later as each bug fix release will be a single 'merge' revision onto your release branch rather than a heap of commits.
So, in summary: I would go with 3 branches, one for dev, one for QA (which is also the main line) and another branch for releases. you can tag each release revision if you know you do not have to maintain old versions, but if you do then that Release branch should be a release branch per release, or major version, of your product.
With git and similar systems, you tend to see more of a feature or team branch strategy as merging is a lot easier than on TFS. With something like svn, you tend to see both types.