On Sun, Feb 25, 2007 at 06:15:35PM -0600, Aaron Spike wrote:
bulia byak wrote:
This cannot be done on the trunk because SVN must be usable for work every day. And it does not seem to me that branches are a successful strategy in general. Work in branches seems rather prone to dying out soon after branching.
I don't think this is strictly true. Filters were done on a branch, and that branch didn't die until it merged back to trunk. Branches can work, but they need the support and energy of two or more coders and lots of organization.
Same with the gtkmm branch - it also got to the point of reintegration with the main codebase. In fact, interest died down only after switching to a refactoring approach.
You could argue that if the work is prone to die out if it's done in a branch, then perhaps there wasn't really sufficient interest in it to begin with. Who's to say that same work wouldn't also die if done in the main codebase. And with a branch if the work fails to reach the point where it can be merged, then at least it isn't going to clutter up the main codebase.
From my own experience, the risk with branches is trying to do too much
in a branch. The longer the branch exists unsynced with main, the harder it gets to merge later on.
Not that I think this work *should* be done as a branch; I bet it can be done with #ifdefs. However, I don't think branches should be dismissed outright. Like any tool they're not a silver bullet but can be very useful in some situations.
Bryce