On Tue, Nov 8, 2011 at 5:34 AM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > Has anybody seen these? > http://draketo.de/proj/hg-vs-git-server/test-results.html#results > > Seems like a potential area of improvement. I think this is a case of designing the problem space so that your intended winner wins and your intended loser loses. 'git gc' is designed so that it can be run out-of-band. It doesn't make a lot of sense to design your application so that the end-user has to wait for git-gc to run, and I don't think anyone ever would. But that is similar to how mercurial works, and that is why the author of that page measured git's performance that way. Off the top of my head, it seems to me that running 'git gc --auto' in a cron job with SCHED_BATCH scheduling and some simple locking may satisfy his requirement of keeping the repository size bounded and ensuring that the pack operation does not affect the operation of the web app. -Brandon -- 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