SVN: trunk, branches and tags

Question

It's a month I'm trying to figure out the best solution to my problem and this is the best one. I would like to know if you agree with it.

We are developing a set of interconnected web applications. We treat each application as a single solution indipendent from the others. Each application is formed by different projects, but this doens't matter much.

We use to develop on the trunk new functionalities. Whenever we publish something live we tag the trunk version with a version name. For example suppose that the first trunk version is tagged 1.0.0. When we develop furhter implementation (i.e. we are working on 1.1.0) a series of bug comes out from the production version. What we are thinking to do is checkout tag 1.0.0 and correct bugs towards version 1.0.1.

Now what we would like to accomplish is to tag EACH revision version. In other words we would like to be able to have a perfect working copy of 1.0.0, 1.0.1, 1.0.2 ...

Now this is my solution, I would like to know if you agree on it.

1. I checkout my tagged version 1.0.0 to the local /tags folder
2. I branch this version to /branches/1.0.1 repository folder
3. I checkout my new branch to the local /branches folder
4. I correct bugs on the branch 1.0.1
5. When, after x commits, everything is ok, I tag this new version to the /tags/1.0.1

and so on for each new bug / new release. I tried it and if I checkout the /tags folder i can see all the versions, perfectyl working.

Now when I'm ready with the 1.1.0 I should merge the last tag (or Branch, they should be the same at the end if everything is correct) on the trunk using "Merge a range of revisions" options. When everything is merged, I should have a fully working 1.1.0 version with the revisions corrected in the past. Compile, test and then publish and, obviously, tag it to /tags/1.1.0 folder on the server.

What do you think? Thanks, Marco

Answer 1

Normally all development is done on trunk, and trunk is what you base releases off. You use branches either to stabilize the code in preparation for a release, to patch a release or to implement a feature that can't be developed on trunk for several reasons.

When using the branch for stabilization or to patch a release, the fix for the bug, or the changes that should go to the stabilization branch are all developed on trunk, and merged selectively to the branch.

When using a feature branch, you commit to the branch and then merge back to trunk (and maybe from there to stabilization/patch branches.

Short story, I miss trunk in your development cycle, and I wonder how you ensure that all changes are eventually in trunk, because that's where your next major feature release will/should start from.

Answer 2

This looks like a pretty good process, except that your bug fixes on the production branches will, in all likelihood, need to be reflected in trunk as well. Therefore, there shouldn't be a need to merge everything into trunk at the end because you will have already done it as you went.

Otherwise, it does seem that you are using branches and tags appropriately, so kudos on that. I've seen far too many projects that could not identify in source control the current (or some other) production version (which, if you need to fix something or roll back, is essential). There's no excuse for that, in my opinion.

Answer 3

What you described sounds like the normal procedure for tagging and branching to me. That's the way I use subversion, and it works very well.

Answer 4

Sounds good to me.

Depending on the ammount of fixes getting released I wouldn't bother with createting branches for every minor release. Creating those, communicating to people what to checkout/where to checkin, merging down etc. Rinse & repeat.

Having a branch for each major release and using that as a "maintenance"-branch works well for us.

here is a description of the process in case you are interested: svn deployment strategies for multiple groups of developers (not co-located) working on different components of the same project

Define policies for branches and create a new branch only if you have to do something that does not fit into current policies. Helps to limit the branching.