I (Julian Foad) wrote:
> To me this algorithm seems better.
My argument for wanting something 'better' than the current trunk
implementation (which flushes after 4, 16, 64, 256 log entries) has
been blown out of the water. My argument depended on an assumption
that the rate of discovery of log entries could be very bursty: for
example, the first 2 entries are both recent and are discovered
quickly, then a long time before the server discovers the 3rd entry
because it is a million revs older. But Stefan has just told me that
is not the case: each log entry to be reported takes a broadly similar
time, related to the depth of the path and the amount of authz
checking, no matter how many million revisions away.
Given that news, there is no reason to want anything different from
the current implementation. Sorry for the noise.
Received on 2015-03-17 18:26:56 CET