Well, branches should continually be merging-in trunk, so once one feature branch was merged back in, all active feature branches should get it. Right? My hope is that trunk has all stable features, and the feature branches have all stable features plus their in-progress feature.
Yes, it's likely that when multiple big feature branches are in flight not all of them will get equal attention, and this may (and probably will) prolong development on individual feature branches. But, if the result is more readily releasable mainline trunk source, I think it's a worthwhile trade off. Sent from my iPhone On Sep 6, 2011, at 6:42 PM, David Smith <catfish....@gmail.com> wrote: > > > > > On Sep 6, 2011, at 6:26 PM, Stephen Holt <sh...@adium.im> wrote: > >> >> On Sep 6, 2011, at 6:18 PM, Evan Schoenberg, M.D. wrote: >> >>> >>> On Sep 6, 2011, at 7:01 PM, David Smith wrote: >>> >>>> I disagree. The concept of "trunk" focuses testing a lot. I know when >>>> we had a few feature branches going I immediately set up my own branch >>>> that I merged them all to so I could test more than one thing at once. >>> >>> Branch early, merge early may be a fine approach. I'm just unclear what >>> advantage branching 1.5 (and, as a result, making trunk 1.6hg) would have >>> at this time. >>> >>> -Evan >> >> >> +1 >> >> As for testing, this is why we're trying to set up nightly builds for >> n-branches. > > Test build *availability* is not the problem with branches. It's that you > have to pick which single feature you're going to live on. If people really > merge early, ok... but that defeats the stability goal. > > David
