Subversion practice with multiple development branches

Question

I used to be working on site in a Federal department. I met a team lead “Jack” there who led a small group of developers specialized in C#, Delphi, or PHP etc. Jack just landed there for around 2 months, and had already pleased the directors of the department by controlling the chaos and presenting the progress through beautiful tables and charts.

In a team meeting, Jack promoted such practice of using SVN:

1. Every developers working on the same project must create a branch, and no developer should be working on the trunk.
2. When each developer finishes his/her part of development work, merge back to the trunk.

Jack commanded every developer to stop submitting codes to the trunk. And This really surprise me, because I had always thought that branching is generally for releases, bug fixes and developer experiments. I was not sure if Jack’s practice could really protect the integrity of the trunk.

How do you think such practice of using SVN with multiple development branches?

Please clarify if you use unit tests as well as Continuous Integration.

Answer 1

Being able to create a separate branch for each developer, and still survive the final merging to trunk, means that the dependency of code development is very minimal in between the several developer specific branches.

The thing is, development integration branch should be the same for all developers, which comes after the local branches(inidividual branches for individual developers). In this branch, the developers shall be mandated to commit their local development branch changes at the end of every day, or after a definite interval.

Answer 2

Disclaimer: I made the most of my experiences with SVN<1.5, so my knowledge of SVN might now be outdated.

What Jack want is the default development model for DVCS like Git or Mercurial. In this world it works fine.

Before we switched to Mercurial in our company, we had the develop-everything-in-trunk model. This caused all kind of nasty problems, because we always stepped on the toes of each other, causing a really painful experience. But the development model which Jack describe does sound like a good mitigation against this problem. I can't tell if this also works in practice, since we made our transition before the 1.5 release came out (which was the SVN version where they started merge tracking). But when the merge tracking now works, it is a good development model.

Answer 3

It's good practice and (as result) it will be easy manageable code (to some degree), if branches name will follow some follow easily decoded naming rules.

I'll disagree with Michael about possibility commit to trunk for fast-fixes, because:

• Dura lex, sed lex
• Merge hell doesn't exist in short-live branches and in long-live with correct merge-policy

Answer 4

Branching needn't only be for releases or experiments. It is also commonly used to work on implementation of significant features which may affect a number of files, when it is impractical to make such significant changes to the trunk. In this way, Jack is on the right track, I would say.

However, the practice of never committing to the trunk may be, in my opinion anyway, a little bit drastic. Small bugfixes and changes are often best committed to the trunk, saving a lot of extra merging when conflicts are less likely to occur, and when other developers have to work out a small bugfix, they don't need to branch again separately from their other current feature development branch, and then merge the small fix back to the trunk.

If this branching strategy has brought success to Jack and his team, they probably ought to stick with it.