Re: on when to checksum

[Tom Lord <lord@emf.net>]

  The thing is, I don't "trickle" things in. That would be horribly 
  inefficient for me. So I go over the patches, make a mbox, and do them all 
  in one go. And then they need to happen _fast_. If it takes 20 minutes, I 
  go away for coffee or something, and then if something didn't apply 
  half-way through, I will have lost my "context".

  That's why I want things instant. Not because I have huge daily throughput 
  issues, but I have huge _latency_ issues. 

I'm curious about what is the value of the "batch" nature of that
proces?

Presumably most patches apply cleanly and most or orthogonal (order
independent).   I'm sure that there are frequently interesting exceptions
but am I generally right about "most" here?

So, if I understand, you review each change before stuffing it in a
mailbox, then you apply all the patches in that mailbox in batch.
In the majority of cases, the buffering of changes in the mailbox
adds nothing.

Why isn't that more automated: when you approve a change, it could be
applied at once, in the background.  If conflictless, it can be committed,
tested, whatever.  If conflicting, *then* the change can be buffered
up for you to look at.   Explicit declarations from programmers or 
text-based computations about dependencies among the patches can help
improve the queue management in more complicated cases.

In other words, a more asynchronous process might save you time *and*
pay off by reserving more of your attention for areas where it's 
really needed.

-t