1 |
On Wed, Oct 27, 2010 at 01:53, Robin H. Johnson <robbat2@g.o> wrote: |
2 |
> The other major problem with splitting the repo, is that the overhead |
3 |
> that will be imposed by it. This got lost during the talks, but I've |
4 |
> followed up with warthog9, and the size is going to hurt. |
5 |
> |
6 |
> In an attempt to explain that better, I've laid out below, the (inode) |
7 |
> overhead costs per checkouts in each VCS, in a variant of O-notation. |
8 |
> d = number of directories, f = number of files, r = number of |
9 |
> repositories. |
10 |
> CVS: O(3d) |
11 |
> SVN: O(8d + 2f) |
12 |
> Git: O(35r) |
13 |
> |
14 |
> All of which represent the bare minimum number of inodes are required. |
15 |
> |
16 |
> Our CVS tree tracks 21481 directories, and 118286 files. |
17 |
> 14302 of those directories are packages. |
18 |
> |
19 |
> For the 3 models of Git: |
20 |
> 1 giant repo: 1 repo only. |
21 |
> repo-per-package: 14302 repos |
22 |
> repo-per-category: 154 repos. |
23 |
|
24 |
Does repo work with a tracker repo that keeps the state of all the |
25 |
child repos, so you still get consistent state? I don't have much |
26 |
experience with git, but I'm a hg developer, so I know a thing or two |
27 |
about VCS. |
28 |
|
29 |
The interesting part is where the tools are such that devs can just |
30 |
not get all the packages/categories they don't work on. If that's |
31 |
impossible, then I think just going with a single repo is probably |
32 |
best. From what I know about how git works, I'd also say that git will |
33 |
deal with a large tree alright (which would be a larger problem in hg, |
34 |
I think). |
35 |
|
36 |
Cheers, |
37 |
|
38 |
Dirkjan |