SVN: personal branches for each developer?

Question

I'll be honest, SVN branches scare me. The last project that I worked on which used them extensively, I seemed to spend half my time testing my branch worked, doing a dummy merge into trunk, doing a real merge - only to find someone else had just committed while I was doing this and I had to update and start over.

On that particular project, branching was done per-developer... there was a trunk and then you had your personal branch, worked on a task and merged the range of revisions back in. It seemed horrific as you had to check each time what the last revision in your branch was that you merged.

Is this paradigm actually good, and I just didn't get it since I'm not used to command-line SVN usage? Or was it a terrible system?

Answer 1

With Subversion, I use "work branch(es)" which are owned by a team and shared by all members of the team as described in the great Version Control for Multiple Agile Teams article and illustrated below:

I warmly recommend to read the whole paper, it's really worth the read.

With something else than Subversion, I may consider using "feature branches" but, to be honest, I don't see the point of personal branches per developer (and it doesn't make sense to me to go beyond the granularity of a feature).

Answer 2

I have never used branch-per-developer. The idea doesn't make sense to me.

To begin with, you should align your development team so that people tend to work on different parts of the source code. If everyone is constantly editing the same files, no technology will really help you keep everyone coordinated.

SVN does a great job of merging different people's edits for those times when people do work on the same files. Write unit tests to help ensure the merged code product still works.

I use branches to maintain the currently released version of the code while developing the next version.