{"thread":{"id":"43675","subject":"Re: Git hosting techniques","startedAt":"2006-11-04T12:08:45Z","lastAt":"2006-11-04T12:08:45Z","messageCount":1,"participants":["Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296578","messageId":"20061104120845.GA18879@pasky.or.cz","threadId":"43675","inReplyTo":"20061029175446.GE12285@localhost.localdomain","subject":"Re: Git hosting techniques","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2006-11-04T12:08:45Z","receivedAt":"2006-11-04T12:08:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hi,\n\n  cc'ing git@vger.kernel.org since this might be interesting for other\nGit people as well.\n\nOn Sun, Oct 29, 2006 at 06:54:46PM CET, Sylvain Beucler wrote:\n> We're currently setting up something similar at\n> http://cvs.sv.gnu.org/gitweb/,\n\n  That's great!\n\n> I would like to know if you considered the ability to autopack\n> repositories to optimize space and disk i/o. For example, we're\n> experimenting with the coreutils repository which weighs 1.1GB. Since\n> you mirror the glibc repository, maybe you have similar issues?\n\n  currently I do it in a rather silly way and when I do an \"all-repo\ncheck\" every hour (which updates mirrors of external repositories etc.)\n- I also check for unpacked objects and if there are any, I will repack\nthe repository; see\n\n\thttp://repo.or.cz/w/repo.git?a=blob;f=updatecheck.sh;hb=HEAD\n\n  This is not an optimal behaviour, for two reasons:\n\n  (i) Full repack can be a lot of work on large repositories, so we\nshouldn't *always* repack but more importantly, we should only rarely do\na full repack - see below.\n\n  (ii) This is very unfriendly to those who fetch over HTTP, because\nafter you do a full repack, they will need to download the whole new\npackfile instead of just the missing objects.\n\n  The best solution would be to have a more intelligent repacking\nstrategy, where you have \"archival\" packs with very old history and an\nactive pack with just the new changes, and when you pack the loose\nobjects they just get appended to the \"current\" pack. Alternatively,\na slightly more complicated but even more flexible \"logarithmic\"\nrepacking strategy could be implemented, see\n\n\thttp://news.gmane.org/find-root.php?message_id=<20051112135947.GC30496@pasky.or.cz>\n\n  Even with the dumb packing strategy though, I think it pays off if you\nhave at least a bit of CPU power to spare. The packing saving are\nreally immense. For example with the glibc repository, an incremental\nCVS import worth of few days of changes _doubled_ the size of the\nrepository (from 100M to 200M), while repacking brought it back to the\noriginal size (100M) + epsilon.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj\n$/=unpack('H*',$_);$_=`echo 16dio\\U$k\"SK$/SM$n\\EsN0p[lN*1\n"}]}