Do you know of anyone effectively using this model?
Chris On Sep 6, 2011, at 9:07 PM, Stephen Holt wrote: > 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
