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 |