Re: [tlug] Open-source repository question

[Curt Sampson <cjs@example.com>]

On 2009-09-28 03:41 +0900 (Mon), Stephen J. Turnbull wrote:

>  >   http://martinfowler.com/bliki/FeatureBranch.html
>
> The whole section "PI vs. CI" is far more supportive of of feature
> branching...

I'm not sure how statements such as, "On the whole, however, I don't
think cherry-picking with the VCS is a good idea" can be interpreted as
supportive of feature branching , except under certain circumstances
where other things are broken. "If you've got these major problems at
the moment, feature branching can help mitigate them to some extent" is
pretty different from "feature braching is the best solution to these
major problems."

> "...it is also a necessary corrective to the greed of the average
> developer for getting his patches into the mainline, and let those who
> commit afterward deal with conflicts with his ill-thought-out patches.

I'll buy this. I will not buy the idea that the "greed of the average
developer" you describe above is a good thing, and that it's not a
problem we should try to fix at the root. I think that having other
developers "deal with conflicts with his ill-thought-out patches" is
mostly a waste of time that the other developers could spend doing
something more productive.

> Build-time configuration changes, when builds are expensive, lead to
> situations where only a small subset of the integration problems are
> actually noticed in many cases.

I can quite easily think of ways to notice more problems with build-time
configuration changes; I'm sure you can, too. And even if it's noticing
only a subset of the configuration problems before the "big merge" hits,
at least you're noticing more than you did before.

Shared-a-little-bit is still better than shared-nothing, and also makes
it considerably easier to move to shared-a-little-bit-more. It's the
first step that's the hardest here.

> Note that I do not claim these are universal tendencies; I am sure
> they are not.  But they do apply, empirically, to the projects whose
> inner workings I am most familiar with.

I'm familiar with these. I just think that using branching to attempt to
paper over the real problems, and otherwise giving up on solving them,
is not the proper long-term fix.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com