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