On Fri, Oct 27, 2006 at 05:03:34PM +0200, Petr Baudis wrote: > Dear diary, on Fri, Oct 27, 2006 at 04:48:39PM CEST, I got a letter > where "J. Bruce Fields" <bfields@xxxxxxxxxxxx> said that... Ya know, it'd be cool if that fit on one line.... > > On Fri, Oct 27, 2006 at 04:38:54PM +0200, Petr Baudis wrote: > > > I don't really like this that much. Big projects can have 10 commits per > > > hour on average, and they also take potentially long time to repack, so > > > you might get to never really repack them. > > > > An average of 10 per minute doesn't mean there aren't frequent long idle > > times. That commit traffic is probably extremely bursty, right? > > 10 per _hour_. :-) Whoops, right. > E.g. GNOME is 7 commits per hour average, and it does tend to be pretty > spread out: > > http://cia.navi.cx/stats/project/gnome > > (Unfortunately I can't figure out how to squeeze more commits from the > web interface. KDE gets even more commits than GNOME and Gentoo tops > all the CIA-tracked projects.) That's not enough to tell how long on average you'd have to wait for a gap of a certain length. I think if you expect x commits per hour, and need y hours to prune, then you should be able to get a worst-case estimate of hours between y-hour gaps from octave -q --eval "1/poisscdf(0,x/y)" but my statistics isn't great, so maybe that's not quite right. And in any case the commit arrival times are probably very far from independent, which probably makes gaps more likely. --b. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html