On 04:39 Mon 01 Nov , Robin H. Johnson wrote:
> On Fri, Oct 29, 2010 at 09:28:34PM -0500, Donnie Berkholz wrote:
> > With 4K blocks, that works out at roughly 500 MB (CVS) to 2 GB (SVN,
> > Git) of inode overhead. I have a hard time imagining people so hard
> > up for disk space that they can fit the whole git repo but can't
> > find another 1.5 GB.
> I'd like to ask the embedded arch folk how they feel about that size
> proposal. I know some of the MIPS team were running 2.1GB SCSI drives,
> and complaining already.
The counterpoint there is that in the largest 4GB case, we'd have a
package per repo so they wouldn't need the whole tree. Even if they had
the whole mips-keyworded tree, that currently amounts to around 1800
packages, roughly 10% of the 4GB I mentioned for a complete,
> > Based on my current git conversion with a pack size of 1.7 GB, I suppose
> > that means the total repo in a git world could vary from ~2 GB all the
> > way up to ~4 GB.
> There is one oversimplification here, that the pack will actually be
> that large...
Yep, grafts are a great point and are worth considering. It's very rare
that we need to access anything from longer than a year ago.
> Is the packfile of the kernel sources an acceptable size? It's
> presently ~800MiB. If we start with zero or minimal history (6 months
> maybe). This gives us a fairly small tree...
I'm not familiar with many of the details of grafts. Is it possible to
push from a history-trimmed tree where there is no existing commit to
the files being changed? Does it just get treated as if there's a single
I'm working on converting a full tree to a single repo per package, but
it takes an awfully long time. Perhaps I'll have a go at trimming
history, then doing repo-per-package, to see what sizes look like.
Combining grafts and package-per-repo seems like it could give our devs
maximal flexibility for workinging in even the tightest spaces.
That said, let's just proceed with the parts everyone agrees on. There's
nothing stopping us from further tweaking the git repos once we're
Sr. Developer, Gentoo Linux