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