On Wed, 16 May 2007, Shawn O. Pearce wrote:
Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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...
-
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
