On Sat, Nov 11, 2006 at 11:48:04PM CET, Jakub Narebski wrote: > Catalin Marinas wrote: > > > IIRC, there was some advise in some GIT document > > or e-mail saying that you shouldn't pack if the export is over a dumb > > protocol. That's good for people pulling regularly but bad for > > cloning. > > By the way, does dumb protocols download _whole_ packs only? Or do they > download parts of packs (curl can do that, I think)? curl can, but it might very easily get even much more expensive than downloading the whole patch unless your latency is very small and bandwidth very tight, which would be quite a unusual situation. It's true that repacking can hurt dumb protocols - if you repack often, dumb clients will have to re-fetch the single whole patck with all the stuff they already have plus the few additional objects they are missing. But at least packing once can be a huge improvement and won't hurt the dumb clients since their problem is with incremental fetches. Furthermore, if you do just repack, not repack -a, the cost for dumb protocols is quite small (though it's not optimal packing strategy): It is not unlikely at all that if you have set of unpacked objects A, client fetches that, then you create set of objects B and then repack, creating pack(A \cup B), this pack will still be much smaller than the set of objects B (even if |A| >> |B|) so it's more beneficial even for the dumb clients to refetch the A objects contained in the pack, instead of fetching just the unpacked B objects. By the way, in case of glibc-cvs the pack sice is 104M, and after importing new CVS changes after few days, the repository size doubled to 200M. git-repack -a -d brought that _back_ to 104M! Packs are a funny thing. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) - 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