Re: [tlug] Open-source repository question

[Curt Sampson <cjs@example.com>]

Stephen Turnbull wrote:

> I would suspect that the peanut gallery is correct here, in that it is 
> more likely for anonymous shared subpatches not to conflict so the extra 
> conflict messages are an annoyance.

More than just an annoyance, they are a cost. Every minute you spend
dealing with false positives is just as much a minute lost as those
spent dealing with false negatives.

And let's face it, truly automatic merging is a pipe dream anyway; if it
weren't, computers would be desiging all our software instead of us, and
we wouldn't need developers any more. Given that, you're always going to
have developers checking merges carefully, in fact, probably, treating
them just as carefully as if they're making a non-merge commit.

My main experience has been that the cost increases with the distance
between two bits of code; merging a one-hour old branch is cheaper than
merging a day-old branch, and for a week-old branch, well, you may be
better off just rewriting the changes from scratch.

> >  > As the H.264 stuff used DMA, these two changes had to have separate 
> >  > branches (in fact as we used CVS, I actually just checked out versions 
> >  > of the source tree into different directories).

Oh dear. Branches may be more difficult in CVS, but surely they are not
*that* much more difficult.

> [Stephen Turnbull writes:]
> 
> > But this is precisely what Curt advocates, no?  Keeping it in a
> > workspace until it's ready to go into the mainline.

Actually, I don't see that much difference. To be more precise about
what I advocate, it's getting the changes down to small enough
incremental chunks that you each piece into the mainline quickly.
Letting a checkout diverge is no different from letting a branch
diverge; you'll still have a merge horror at the end.

> > The point of a branch is communicating (either with other developers
> > or a forgetful incarnation of yourself :-).

This is what I don't buy. The point of a branch is to avoid contact with
others, and delay having to work out the real effect of your changes on
work others are doing. Otherwise why would you need to make sure that
you don't see others' changes, and they don't see yours?

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