www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: git for other open source projects
Date Thu, 28 Feb 2008 16:04:01 GMT
On Thu, Feb 28, 2008 at 2:52 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>  I also recall seeing something similar (checkout including a local
>  copy of relevant version history) being discussed on the Subversion
>  mailing list some while ago. I'll see if I can dig it up, or perhaps
>  someone closer to Subversion knows better.

svk can do that.

But, it's tremendously expensive disk-space-wise and bandwidth-wise as
you have to have the entire relevant copy of the repository locally.
Again, git (and *most* dSCMs) are not intended for 'large' modules -
'modules' much bigger than say the Linux kernel tend to be where
things fall over.  kde is splitting out each 'library' into its own
separate git repository because it can't handle things much bigger
(and that's also how Linus recommends usage of git).  For small
repositories like that, it's super easy to make it go fast!  Try to do
it for over 40 million unique files in a single module and see how it
does!  So, to follow the KDE model, every component in, say, Tomcat
would have to be in separate repositories.  As such, there'd be a
follow-on effect if we switch to an SCM that isn't effective for large

Also, we currently disable most replay usage (which'll break svk and
git-svn and others) because our SVN server is already way beyond
overloaded.  The LA on the box is usually consistently around 12 and
it gets hit by lots of DDoS's every day.  When we deploy the new EU
mirror (hopefully in April), I'm hopeful we might be able to loosen
the restrictions somewhat.  However, right now, the technical priority
is to serve all of our normal SVN clients and not worry about people
using non-standard clients.  Again, that's just an aspect of the fact
that we don't have sufficient server resources at our disposal - not
an intrinsic problem with Subversion.  (The server is over four years
old and woefully underpowered for what it's handling today.)  --

View raw message