The historical linux archive has a lot more than 300,000 objects. In fact,
even the _current_ kernel archive has almost 200,000 objects.
Maybe somebody was thinking "commits", not "objects". Something with
300,000 commits is indeed a pretty big project.
Anyway, from a scalability standpoint, git should have no problem at all
with tons of objects, as long as you pack the old history. There are a few
things that get slower:
- if you end up doing things that look at history, they are obviously at
least linear is history size. Often there are other downsides too
(using lots of memory).
Example: try even just a simple "gitk" on the (regular, new) kernel
archive, and it will take a while before the whole thing has been done.
Of course, you'll see the top entries interactively, so mostly you
won't care, but I routinely limit it some way just to make it not make
the CPU fans come on. So I do something like
gitk --since=1.week.ago
gitk v2.6.15..
instead of plain gitk, just because it makes operations cheaper.
- a full clone takes a long time. Git _could_ fairly easily have an
extension to add a date specifier to clone too:
git clone --since=1.month.ago <source> <dst>
and just leave any older stuff (you could always fetch it later), but
we've just never done it. Maybe we should. It _should_ be pretty simple
to do from a conceptual standpoint.
but "everyday" operations shouldn't slow down from having a long history.
I can still apply 4-5 patches a second to the kernel archive, for example,
as you can see from
git log --pretty=fuller | grep CommitDate | less -S
and looking for one of the patch series I've applied from Andrew..
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
