| 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 |
Archives