| 1 |
On Sat, 15 Dec 2018 23:15:47 -0500 Alec Warner wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> I am currently embarking on a plan to redo our existing rsync[0] mirror |
| 5 |
> network. The current network has aged a bit. Its likely too large and is |
| 6 |
> under-maintained. I think in the ideal case we would instead pivot this |
| 7 |
> project to scaling out our git mirror capabilities and slowly migrate all |
| 8 |
> consumers to pulling the git tree directly. To that end, I'm looking for |
| 9 |
> blockers as to why various customers cannot switch to pulling the gentoo |
| 10 |
> ebuild repository from git[1] instead of rsync. |
| 11 |
> |
| 12 |
> So for example: |
| 13 |
> |
| 14 |
> - bandwidth concerns (preferably with documentation / data.) |
| 15 |
> - Firewall concerns |
| 16 |
> - CPU concerns (e.g. rsync is great for tiny systems?) |
| 17 |
> - Disk usage for git vs rsync |
| 18 |
> - Other things i have not thought of. |
| 19 |
|
| 20 |
My main concern with git is downlink fault tolerance. If rsync |
| 21 |
connection is broken, it can be easily restored without much data |
| 22 |
retransmission. If git download connection is broken, it has to |
| 23 |
start all over again. So there are cases where rsync will be always |
| 24 |
much more preferable than git. |
| 25 |
|
| 26 |
Best regards, |
| 27 |
Andrew Savchenko |
Archives