Re: Smart fetch via HTTP?

On Wed, 16 May 2007, Shawn O. Pearce wrote:

Johannes Schindelin [off-list ref] wrote:

quoted

quoted

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...