seeking recommendations for CM METHODOLOGY of small project development with SVN

Question

we are a small startup company, starting from scratch. We use Subversion, the repository is located on a Web-based service.

I am familiar with CVS and read some intro to SVN, that's not a big deal. I am interested in references to CM methodology that will allow us to spend the least effort on the CM per se, but will enable us to work smoothly without conflicts. I am sure that no wheel need to be reinvented, I just want to confirm the idea that I have.

What I have in mind is:

• each developer starts his private development branch
• when done, it is merged to the integration branch. further stabilization is done on the integration branch.
• when the integration is done, it is merged to the trunk and tagged.

I am unclear of:

• should we start a new private branch from the trunk after that, or keep working on the same private development branch?
• I see that svn has a special behavior when reintegrating back on specifically on trunk. Are there benefits (or drawbacks) in having a special integration branch, then?

thanks a lot.

Answer 1

Why do you feel the need to do development in private branches? Can't you have your developers work together, in the same repository path? The reason I ask is in my experience, most people that think they "need" this are usually wrong and don't understand source management and how Subversion works. I'm not accusing you of this but I am hoping you can explain the reasoning behind this requirement, as it might have an impact on future suggestions.

To attempt to answer your question, I can tell you that using private developer branches will add unnecessary burden to your administration and tooling configuration. Developers should be working together in the same repository path, unless there is good reason like using a branch a bugfix release or experimental effort. There are many reasons for this but the first few that come to mind for me are that development is a team effort, visibility into everyone's changes, simplicity in development processes, simplicity in tooling configuration and simplified administration.

Typical Subversion usage has the trunk be the path where all developers work on the next release. You create branches to do isolated parallel development for things like bugfix releases, experimental features and long running development tasks for example. We all know that all scenarios aren't typical and each team's needs are unique but until I know why you need private developer branches, I'm going to disagree that they are needed and that they will add unnecessary burden to your team, processes and tooling configuration.

Answer 2

I would start with only a trunk branch with maintenance branches for releases if needed. That usually is a good default. This will generate surprisingly few conflicts and will drive development towards "make small change often" which is a good thing. I have experienced this with team size of 1-10 developers and it works. This is called "release branches" in Subversion doc.

Feature branches is another common way to operate. Here you create a new branch for each new feature and merge features back to trunk. One developer might have several feature branch simultaneously or several developers might work on same feature branch at the same time.

Having a branch for each developer requires that you will make a lot of merges and they will be painful.

---

To answer your two unclear point: You should definitely make a new feature branch starting from the trunk after you have integrated the feature branch back to trunk. Subversion docs recommend to stop using old branch.

In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again. For this reason, if you want to keep working on your feature branch, we recommend destroying it and then re-creating it from the trunk:

However there is nothing special about trunk branch, it is a normal branch in every fashion. It just has a different kind of name than other branches. Thus there is no special about reintegrating to trunk. Subversion docs talk about --reintegrate operation but it refers to following case:

1. You have branch A (in many cases this would be the trunk)
2. You make a new branch B from branch A
3. You modify branch B and possibly also branch A
4. You merge or reintegrate changes from branch B to branch A.