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