Gentoo Archives: gentoo-scm

From: Donnie Berkholz <dberkholz@g.o>
To: "Robin H. Johnson" <robbat2@g.o>
Cc: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] repo layout & graft / split-history
Date: Mon, 01 Nov 2010 17:33:31
In Reply to: [gentoo-scm] repo layout & graft / split-history by "Robin H. Johnson"
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, full-history tree.
> > 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 initial commit? 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 actually converted. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: