| 1 |
On Thu, 8 Apr 2021 20:22:25 +0300 Joonas Niilola wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> On 4/8/21 7:37 PM, Alec Warner wrote: |
| 5 |
> > |
| 6 |
> > It's admittedly a grey area here. We use CDNs for various web |
| 7 |
> > components (packages.gentoo.org for example) and we use a CDN for |
| 8 |
> > distfiles.gentoo.org. Is Github simply a CDN for gentoo.git? Its an |
| 9 |
> > open question we have discussed on the gentoo-nfp list. |
| 10 |
> > |
| 11 |
> > In general I'm not really sold on the benefits of git as a replication |
| 12 |
> > protocol; while I dislike running a global rsync network the |
| 13 |
> > maintenance of the network is basically nil from infra's end and so I |
| 14 |
> > don't feel significant pressure to move to git. Could you perhaps |
| 15 |
> > articulate why you think it's important for clients to move to git? |
| 16 |
> > |
| 17 |
> > -A |
| 18 |
> > |
| 19 |
> |
| 20 |
> It provides much better user experience with continuously faster |
| 21 |
> sync-times. Also there's error posts frequently in the forums when using |
| 22 |
> rsync, even recently. |
| 23 |
|
| 24 |
Only if you have fast and reliable uplink. Try to terminate sync |
| 25 |
connection and resume in cycle. Rsync will do the job and recover, |
| 26 |
so users will be able to sync on poor connection; git will start |
| 27 |
over again and again, and again… Git can't continue failed |
| 28 |
transfer, it will restart it from scratch. Second try will be |
| 29 |
likely faster due to server-side cache, but a bulk transfer itself |
| 30 |
can't be resumed, only repeated. |
| 31 |
|
| 32 |
Try to fetch historical git using git clone by the way. |
| 33 |
|
| 34 |
Best regards, |
| 35 |
Andrew Savchenko |
Archives