SVN Branching/Merging with feature branch and Production branch

Question

Since we are developing on a deployed system, we are trying to make better use of branching--Up until recently just about everything was just checked into trunk, deployed to test/staging and then production. It means we have to be really careful during the "Testing" period, and we'd still occasionally get unwanted changes sent to the server with little testing.

My thought is that the best way would be "Minor" patches go straight to trunk, major features become feature branches that are reintigrated into trunk when complete, and a "Production" branch that always matches the server state that we can merge into just before deploying.

The main benifit offered here is that you can pick and choose what changes to roll out to production--if you like you could grab a single checkin or branch and send it to production without involving all the other branches.

On the other hand, it seems to be best to have branches Integrate with trunk often--pull up changes so they don't accumulate and make a nasty merge.

So those two patterns could lead to the case where you wish to merge a branch with Production to bring over an imporant feature but that branch has already "pulled in" changes from trunk you don't want to ship.

Can SVN handle this? Are there really good practices that work for groups developing code that is deployed every couple weeks?

Solution

I think that all of what you describe is possible with (a current version like 1.7 or 1.8 of) Subversion. Here are the steps to take:

1. Describe your branching (and merging) strategies. You cannot easily mix all of them, and it is difficult for developers to know which strategy is used where, so documentation and communication is here key. See the following resources:
   • Best branching strategy when doing continuous integration?
   • Common Branching Patterns
2. You will use the following:
   • Release branch for the production release, patches are developed directly there. For each patch, you have to decide, if that patch should be available (in the same form) in the next release.
   • Use the trunk for the main development. Everything you are sure that will be in the next release should be developed on the trunk. Don't merge from the trunk to (release) branch. Never ever!!
   • Use feature branches only if you are unsure if a feature will make it to the next release. Feature branches are (in Subversion) much more difficult than e.g. in Git, so there should be a reason to use them. Merge all changes from the trunk to the feature branch regularly, and only reintegrate at the end, when the feature is integrated in the trunk (to make it to the next release).
3. Find the right point in time for doing the branching and merging:
   • Branching: When is a stable release branch necessary (for integration to the next release), and when can development start for the following release (then on the trunk again)?
   • Merging: When is the best time to merge changes: Immediate, when the change is fresh; regularly from time to time; (hopefully not) only once at the end.

Your branches will be developed over time like this:

1. You start with the trunk (and only the trunk) for release 1.0, your first release.
2. You branch the trunk, when you want to do integration testing for release 1.0, and start development for release 1.1 (on the trunk).
3. You deliver release 1.0, and provide afterwards patches directly from the branch.
4. You branch the trunk, when you want to do integration testing for release 1.1, and start development for the release 1.2 (or 2.0) on the trunk.
5. ... and so on ...

Branching and Merging of the SVN Red Book explains everything that you need technically, but is not so clear how to do it in different business contexts (my personal opinion). I don't have found a resource that explains all options and drivers behind them in enough detail ...

Comments

[Sameer Singh]

Personally, I would treat trunk as king: no development happens there, only merges from feature branches created off trunk. You do your usual QA on a feature branch, and once it's signed off, merge it back into trunk. Then, tag trunk and push that off to production. New feature branch off trunk, and the cycle begins again. If there's a bug that must be fixed immediately, create a bugfix branch off trunk at the tagged revision, fix the bug, do QA, then merge it back again, tag and release to production. It's very easy to follow this workflow once you do a few releases. Just my two cents.

[Bill K]

Is there any way to handle the case where a feature is checked into trunk, other feature branches merge those changes up then are re-integrated into trunk--but then you want to ship without the first feature?

[Bill K]

Was just playing with SVN and I think I answered my own question--"Revert changes made by this revision" seems to do the job quite nicely.