From: david@lang.hm Date: Thu, 17 May 2007 01:04:55 GMT Subject: Re: Smart fetch via HTTP? Message-ID: In-Reply-To: <20070517010335.GU3141@spearce.org> On Wed, 16 May 2007, Shawn O. Pearce wrote: > Johannes Schindelin wrote: > >>> And for services like SF.net it'd be a safe low-cpu way of serving git >>> files. 'cause the git protocol is quite expensive server-side (io+cpu) >>> as we've seen with kernel.org. Being really smart with a cgi is >>> probably going to be expensive too. >> >> It's probably better and faster than relying on a feature which does not >> exactly help. > > Yes. Packing more often and pack v4 may help a lot there. > > The other thing is kernel.org should really try to encourage the > folks with repositories there to try and share against one master > repository, so the poor OS has a better chance at holding the bulk > of linux-2.6.git in buffer cache. do you mean more precisely share against one object store or do you really mean repository? David Lang > I'm not suggesting they share specifically against Linus' repository; > maybe hpa and the other admins can host one seperately from Linus and > enourage users to use that repository when on a system they maintain. > > In an SF.net type case this doesn't help however. Most of SF.net > is tiny projects with very few, if any, developers. Hence most > of that is going to be unsharable, infrequently accessed, and uh, > not needed to be stored in buffer cache. For the few projects that > are hosted there that have a large developer base they could use > a shared repository approach as I just suggested for kernel.org. > > aka the "forks" thing in gitweb, and on repo.or.cz... > >