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.