I (Julian Foad) wrote: > To me this algorithm seems better. Oops.
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. - Julian
