Re: [tlug] Open-source repository question

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > 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.

John Fremlin wrote that; I disagree with it.

 > 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.

Sure.  However, there are two facts about these errors: (1) there's a
Heisenberg principle for errors: you can minimize false positives to a
pretty much arbitrary degree, and you can minimize false negatives to
a pretty much arbitrary degree, but given a rate of false positives
there is lower bound to the number of false negatives, and the lower
the rate of false positives, the bigger that lower bound gets.

(2) It is not that case that all procedures for identifying errors are
efficient (== achieve the lower bound).  In fact, for most procedures
there are ways of reducing the number of false positives without
increasing the number of false negatives.

Exploiting (2) is what a "theory of patches" is about, IMO.

And by the way, (3) although 1 minute = 1 minute (and I nevvah woulda
known it if ya hadna tol' us, yeah right d'oh), it is not true that
the average cost of a false positive in minutes is the same as that of
a false negative; for most procedures, and with a half-decent merge
tool, it's much, much less.

 > 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.

This simply is not possible unless you are the boss.  The result of
having multiple bosses is ... cover your ears children, I'm going to
say something that young-uns shouldn't hear ... "Emacs."  Like the
human genome, as a product of natural selection it's amazingly
functional, but analysis of the content reveals nothing less than
sheer confusion.

 > Letting a checkout diverge is no different from letting a branch
 > diverge; you'll still have a merge horror at the end.

No, it's actually much worse in a checkout, because checkouts cannot
take advantage of metadata about cherry picks and previous partial
merges.

 > > > 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?

Because a large decentralized project's repository is like an
ethernet.  The whole banana is collision management.  So you want to
have bursty transmissions, which keep the information content of each
"packet" high, while keeping the number of collisions low.