Using SVN with multi-release development

Question

My team is using SVN to manage their source control. I have been given the task to see if there is anyway to improve the way in which we use SVN.

I have read much of the SVN book and done a lot of research into how others use SVN.

I'm going to give an overview on how we use svn and hopefully someone has some suggestions for me.

First of all, we have a release every month or two. So currently we use the trunk as our production copy of the code and we create a release branch for each scheduled delivery and for each production fix.

We usually have two, sometimes three scheduled deliveries going at the same time. For example I might be coding for release 3, but I or others are testing for release 2 and doing final bug fixes for release 1. There might also be a production fix going on at the same time.

Right now we do a lot of merges to keep the branches(each release) in sync. Release 3 needs the code from 2 and 1, but we obviously don't want new code from release 3 getting into release 1. So we would do a series of merges from release 1 to release 2 and from release 2 to release 3. This would have to be repeated on a regular basis to that coders on release 3 have and bug fixes from 2 or 1.

Whenever a release or production fix goes into production we merge the code back into the trunk. Then we merge it from the trunk (or the release branch that just went to production) into all the active branches.

As you might have noticed we spend a lot of time merging.

This is a lot of work for the person in control of the source control. They are constantly doing merges and making sure they keep track of which branches are merged where.

It seems like SVN as our source control management system (I know it's really only version control, but we are using it to manage our source control) should be able to help us out with this.

For example, it would be great if the developer working on Release 3 knew when something changed on release 2, release 1, or the trunk and that developer could be automatically notified and he could do a merge to get the changes into his branch. But instead someone has to know to do all the merges manually... Seems like the human is doing too much work and the machine is not doing enough.

Does anyone have any ideas on how we might be able to better utilize SVN's features so we could save ourselves some of this headache, and make sure that everyone is always working with the versions of code they are supposed to be!

Thanks!

Answer 1

I do not know that you can realistically work out a situation like this via questions and answers on a forum. Your best option might be to look at Professional Services from a company like my employer, CollabNet. Subversion Training Options

Let's set aside names like "trunk" for a moment as these things mean whatever you want them to mean. I am one of the committers for Apache Subversion and I would recommend doing development somewhat like we do for Subversion itself.

1. Virtually all development is done in a single location that we call trunk, but could be called "development" or "unstable" or whatever name you want.
2. Some work on new features will be done on feature branches created from trunk. These are generally short lived and at the discretion of the developer. We try to keep our trunk stable at all times (all tests pass), so sometimes people want to try disruptive changes on a branch first.
3. At some point, we think trunk has gotten the features we want to a point that it is time to make a release, so a release branch is created by copying trunk.
4. We do not allow any development to happen in the release branch. Bugs are fixed in trunk, and the revision(s) that contain the fix are nominated for backport to one or more releases. If approved, then the revision(s) are merged to the release branch(s) they were approved for.
5. Occasionally, trunk has diverged enough from the release that a fix will not merge cleanly. When this happens we make a backport-branch by copying the release branch and then merging the fix from trunk to the backport-branch. This allows the developer the ability to appropriately resolved the merge conflicts on the branch and the other developers to properly review and vote for whether the bug should be backported.

This model works well because changes always only merge in one direction and you do not have to worry about someone making a quick fix for some release and then forgetting to make that same fix in trunk. So the bug does not show back up in the next release.

I will point out that Subversion development is fairly linear. We do not have 3 releases in flight as you indicate above. We do still support 3 releases at a time, but the number of fixes being backported is small. I think this process could work for a more fluid environment like you describe, but I think you would be better off having a services professional to work with more closely as you try to iron it out.