1 |
On 06-08-2011 22:42:33 +0200, Krzysztof Pawlik wrote: |
2 |
> To be honest I don't like that idea. I don't see any benefits from doing so: |
3 |
> - tree generation is dynamic - actually I think this is a disadvantage, it has |
4 |
> a nice potential to eat a lot of resources on master rsync server, also having |
5 |
> different "flavours" of the tree only brings in added complexity |
6 |
|
7 |
To be honest, I don't see any problem there. The rsync master server is |
8 |
a modern machine. Generating multiple trees, hardly takes more since |
9 |
all repos in use are shared, of course. |
10 |
With the prefix rsync tree generation [1] in mind, I think the extra |
11 |
cost timewise aren't too bad either. |
12 |
|
13 |
> So: |
14 |
> - having it all in single repository means that I need to care only about one |
15 |
> thing, not around 14956 of them |
16 |
|
17 |
subtrees would help you here |
18 |
|
19 |
> - git was designed to be efficient with large repositories, use this ability |
20 |
|
21 |
I'm not claiming git is inefficient. I think our current model is not |
22 |
very flexible. An alternatives like the one I proposed solves certain |
23 |
problems that currently exist within Gentoo. |
24 |
|
25 |
|
26 |
[1] http://stats.prefix.freens.org/timing-rsync0.png |
27 |
|
28 |
-- |
29 |
Fabian Groffen |
30 |
Gentoo on a different level |