|
To branch or not to branch.
I've been using Subversion for awhile, and now since I've got a web browsing facility that actually works pretty well (more information here http://www.baus.net/archives/000069.html), I have to say I'm pretty happy with it...
In fact I am so happy with its copying and branching support, that I'm considering a whole different method of use. I know other people use this method, and I was wondering what they thought.
I am considering using branches extensively. Not just upon release, but for every new feature. Basically what I want to do is keep the trunk pretty clean, and use branches for development. Say we're working on new logging features. A branch is created for that feature. The developers work on that branch. When the feature is complete then it is merged back into the trunk.
This sounds like a great idea, but I'm afraid it might end up in chaos, especially when features start to deviate from each other.
Any thoughts?
christopher baus (www.baus.net)
Thursday, March 25, 2004
My opinion is that svn's merging capabilities are not sufficient to support this development style well enough. In particular any attempt at "repeated merging" will be a disaster without very careful pre-planning and execution.
Of course, if you'd been using GNU arch http://www.gnu.org/software/gnu-arch/, you wouldn't have this and other problems.
Robert
Thursday, March 25, 2004
This can work if people keep in sync frequently.
The problem is if you have 20 features
scheduling the integration of those features
back into the main release line can be a
nightmare. You'll have to make a merge schedule
of who does what when. Then each merge
needs to be tested. This can be time consuming
depending on your project.
The advantages are:
1. features can be delayed to other releases
2. developers have controlled environments into which they can submit any time they want
3. developers control when to sync
A medium path is to combine several features into
a branch instead of one to a branch.
son of parnas
Thursday, March 25, 2004
We use extensive branching similar to what you are describing and it works very well for our purposes. Our team has four developers and five products built on a common set of core capabilities.
bud
Thursday, March 25, 2004
I'll take the bait. Explain how arch's merging is better than subversion's? My feeling with arch is that it isn't ready for production. Does arch suport a three way (trunk, branch, and common) merging like Perforce?
christopher baus (www.baus.net)
Thursday, March 25, 2004
Merge changes early and often.
Doug Withau
Thursday, March 25, 2004
The advantages are:
1. features can be delayed to other releases
2. developers have controlled environments into which they can submit any time they want
1 & 2 I think are the really big advantages.
christopher baus (www.baus.net)
Thursday, March 25, 2004
The disadvantage is that integration becomes a specific and sizeable task, especially if you're going to merge a bunch of these things at once.
To me, that's too big a downside.
Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, March 25, 2004
The one thing I like about the integration (at least in concept) is it forces a code re-review. Currently code gets checked into the main branch and it is forgotten. Now code will have to be checked into the development branch and slowly promoted to the release branch, where the implications will have to be carefully considered. I guess I'd like some real world examples of this working or not working.
christopher baus (www.baus.net)
Thursday, March 25, 2004
Christopher, i have seen the opposite. The problem
is on feature branches there is no code review.
Then when it is integrated into the main line there
is no review because the merge is often rather
mechanical.
son of parnas
Thursday, March 25, 2004
You should only branch as a last resort. It's a lot easier to maintain a single version of your code, and continuous test that your latest and greatest code always works. That way, you only have one version to maintain. And you don't have to waste time merging branches.
The only time I've branched is when I needed to make a rapid small fix to an older version of the code that a customer is using. That should be a rare event.
Julian
Friday, March 26, 2004
Be really really sure that you want to do this, it can get awfully complicated. Whether it is worth the effort or not depends entirely on your situation.
Friday, March 26, 2004
I would recommend reading this whitepaper which discusses different styles of using branches, especially the section about the pitfalls of certain styles. I would advise that too many concurrently active branches is a receipe for disaster.
http://www.cmcrossroads.com/bradapp/acme/branching/
Mark Johnson
Friday, March 26, 2004
 Recent Topics
Fog Creek Home
| 
