[gentoo-project] Call for agenda items - Council meeting 2021-04-11

[gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

Hi everyone, 

on 11 April at 19:00 UTC the Gentoo council will meet again at #gentoo-council. Please provide agenda items you would like to be discussed and voted on as a reply to this email.

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 501 bytes --]



On 4/7/21 9:31 PM, Andreas K. Huettel wrote:
> Hi everyone, 
>
> on 11 April at 19:00 UTC the Gentoo council will meet again at #gentoo-council. Please provide agenda items you would like to be discussed and voted on as a reply to this email.
>
> Cheers, 
> Andreas
>
Hey,

Can we start using git as the default sync-type on new installations?
Why hasn't this been switched yet?

If nothing else the handbook should noticeably mention git-syncing as an
alternative.

-- juippis


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Wed, Apr 7, 2021, 21:51 Joonas Niilola <juippis@gentoo.org> wrote:

>
>
> On 4/7/21 9:31 PM, Andreas K. Huettel wrote:
> > Hi everyone,
> >
> > on 11 April at 19:00 UTC the Gentoo council will meet again at
> #gentoo-council. Please provide agenda items you would like to be discussed
> and voted on as a reply to this email.
> >
> > Cheers,
> > Andreas
> >
> Hey,
>
> Can we start using git as the default sync-type on new installations?
>

No.

Why hasn't this been switched yet?
>

We don't have the infrastructure to support this yet. E.g. if we told
people to do it our anon git service would likely fall over and stop
working.


> If nothing else the handbook should noticeably mention git-syncing as an
> alternative.


> -- juippis
>
>

[-- Attachment #2: Type: text/html, Size: 1756 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 640 bytes --]



On 4/8/21 5:09 PM, Alec Warner wrote:
>
>
> On Wed, Apr 7, 2021, 21:51 Joonas Niilola <juippis@gentoo.org
> <mailto:juippis@gentoo.org>> wrote:
>
>     Why hasn't this been switched yet?
>
>
> We don't have the infrastructure to support this yet. E.g. if we told
> people to do it our anon git service would likely fall over and stop
> working.
>
>
I like the "yet" part. Meantime, default to Github/gentoo-mirror?

One thing I was also thinking, how heavy is git as a package compared to
rsync in stage3. But to me, doesn't sound heavier at all, especially if
it's built with a lot of USE flags off.

-- juippis


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Matt Turner]

On Thu, Apr 8, 2021 at 11:03 AM Joonas Niilola <juippis@gentoo.org> wrote:
> On 4/8/21 5:09 PM, Alec Warner wrote:
> > On Wed, Apr 7, 2021, 21:51 Joonas Niilola <juippis@gentoo.org
> > <mailto:juippis@gentoo.org>> wrote:
> >
> >     Why hasn't this been switched yet?
> >
> >
> > We don't have the infrastructure to support this yet. E.g. if we told
> > people to do it our anon git service would likely fall over and stop
> > working.
> >
> >
> I like the "yet" part. Meantime, default to Github/gentoo-mirror?

I think you know that that's not going to be an acceptable solution
for many people.

> One thing I was also thinking, how heavy is git as a package compared to
> rsync in stage3. But to me, doesn't sound heavier at all, especially if
> it's built with a lot of USE flags off.

% equery size net-misc/rsync dev-vcs/git
 * net-misc/rsync-3.2.3-r2
         Total files : 31
         Total size  : 979.02 KiB

 * dev-vcs/git-2.26.3
         Total files : 638
         Total size  : 31.70 MiB

A bit of a difference :)

I agree that we should be trending towards using git for emerge --sync.

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Alec Warner]

On Thu, Apr 8, 2021 at 8:03 AM Joonas Niilola <juippis@gentoo.org> wrote:
>
>
>
> On 4/8/21 5:09 PM, Alec Warner wrote:
> >
> >
> > On Wed, Apr 7, 2021, 21:51 Joonas Niilola <juippis@gentoo.org
> > <mailto:juippis@gentoo.org>> wrote:
> >
> >     Why hasn't this been switched yet?
> >
> >
> > We don't have the infrastructure to support this yet. E.g. if we told
> > people to do it our anon git service would likely fall over and stop
> > working.
> >
> >
> I like the "yet" part. Meantime, default to Github/gentoo-mirror?

It's admittedly a grey area here. We use CDNs for various web
components (packages.gentoo.org for example) and we use a CDN for
distfiles.gentoo.org. Is Github simply a CDN for gentoo.git? Its an
open question we have discussed on the gentoo-nfp list.

In general I'm not really sold on the benefits of git as a replication
protocol; while I dislike running a global rsync network the
maintenance of the network is basically nil from infra's end and so I
don't feel significant pressure to move to git. Could you perhaps
articulate why you think it's important for clients to move to git?

-A

>
> One thing I was also thinking, how heavy is git as a package compared to
> rsync in stage3. But to me, doesn't sound heavier at all, especially if
> it's built with a lot of USE flags off.
>
> -- juippis
>

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 1476 bytes --]



On 4/8/21 7:37 PM, Alec Warner wrote:
>
> It's admittedly a grey area here. We use CDNs for various web
> components (packages.gentoo.org for example) and we use a CDN for
> distfiles.gentoo.org. Is Github simply a CDN for gentoo.git? Its an
> open question we have discussed on the gentoo-nfp list.
>
> In general I'm not really sold on the benefits of git as a replication
> protocol; while I dislike running a global rsync network the
> maintenance of the network is basically nil from infra's end and so I
> don't feel significant pressure to move to git. Could you perhaps
> articulate why you think it's important for clients to move to git?
>
> -A
>

It provides much better user experience with continuously faster
sync-times. Also there's error posts frequently in the forums when using
rsync, even recently.

The way I see it, utilizing Github, it can already be implemented
world-wide (wrt rsync mirrors). And those disliking Github can still
keep using rsync, or pick the Gentoo-infra hosted sync-repo (until it
breaks). And regarding that, didn't you say you have a lot of money
needing to be used? ;)

Now I don't know if it's actually *doable* already, or if this is one of
those things nobody brought up yet. That's why I made the post. (infra,
releng, handbook). If it *is* doable, I don't see why the defaults can't
be updated to use git. At some point at least, once we figure out the
global requirements.

-- juippis


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Alec Warner]

On Thu, Apr 8, 2021 at 10:22 AM Joonas Niilola <juippis@gentoo.org> wrote:
>
>
>
> On 4/8/21 7:37 PM, Alec Warner wrote:
> >
> > It's admittedly a grey area here. We use CDNs for various web
> > components (packages.gentoo.org for example) and we use a CDN for
> > distfiles.gentoo.org. Is Github simply a CDN for gentoo.git? Its an
> > open question we have discussed on the gentoo-nfp list.
> >
> > In general I'm not really sold on the benefits of git as a replication
> > protocol; while I dislike running a global rsync network the
> > maintenance of the network is basically nil from infra's end and so I
> > don't feel significant pressure to move to git. Could you perhaps
> > articulate why you think it's important for clients to move to git?
> >
> > -A
> >
>

So I want to discuss two thrusts here then. One is that your argument
below is not very convincing (because it has no data that I can use to
verify anything you said) and the second is just the social contract;
like we are basically saying "hey we can't make git work, so we are
going to use a non-free solution" and is that OK; I happen to think it
is not, but see more below.

> It provides much better user experience with continuously faster
> sync-times. Also there's error posts frequently in the forums when using
> rsync, even recently.

I don't want to dig too deep here, but I'm looking again for more
engineering focussed stuff. If we are going to make a technical
argument, make a technical argument.
"it provides a much better user experience" and "it's faster" are not
arguments; or, they are insufficient to convince me of much. I did do
some experimentation.

For example on my box:
 rsync takes about 5s for an up-to-date-check.
 rsync takes about 1m for a daily-like sync (includes up-to-date
check, incremental delivery, and GPG verification with WKD.)
 rsync takes longer for a full sync, but I tend to use web-rsync for that task.
 Github seems to have taken about 4s for an empty sync (e.g. up to date)
 Github seems to have taken about 6s for a small sync (e.g. daily)
 Github seems to have taken 20s for a full sync.

My git-sync verification doesn't seem to be working (isn't it supposed
to check tip-of-free for a sig? It errors out on me.)

I'm skeptical people care deeply about how long syncing takes (60s and
5s are both fast enough for me; but I sync once a day or less.) I
agree prima facie that Github is likely more reliable than rsync for
most users as it's a better maintained product with a scalable
interface.

I also make a repo for anongit.g.o and it's very slow; probably 10-20x
slower than github. We know we have a bunch of tuning to do on the
git-serving side but no staff to do it.


>
> The way I see it, utilizing Github, it can already be implemented
> world-wide (wrt rsync mirrors). And those disliking Github can still
> keep using rsync, or pick the Gentoo-infra hosted sync-repo (until it
> breaks). And regarding that, didn't you say you have a lot of money
> needing to be used? ;)

So two things here. One is that we should care about the social
contract and I think bi-furcating the core parts of gentoo into free
and non-free is a non-trivial change. If we move people to git syncing
and github makes some changes, or goes away, or whatever...it's not
like we have equivalent free setup; our git hosting is literally not
up to the task of serving those users. I think this is the difference
between the core offering (e.g. "gentoo") and the non-free software in
the tree (the add-ons or additional functionality, or whatever.)
Keeping that logic, we could keep rsync as the default sync method and
tell people to use github if they want (syncing from github works
today just fine.) I think that is different from making github the
default git sync provider. I think this is similar in concept to say,
having only free software by default; which is a change we made
somewhat recently, iirc.

This is less true for our CDN stuff, where we could just turn off the
CDN and be fine[0].

>
> Now I don't know if it's actually *doable* already, or if this is one of
> those things nobody brought up yet. That's why I made the post. (infra,
> releng, handbook). If it *is* doable, I don't see why the defaults can't
> be updated to use git. At some point at least, once we figure out the
> global requirements.
>
> -- juippis
>

[0] This is an engineering argument, is the CDN a latency cache (make
things fast) or a capacity cache (make it so our origin servers do not
melt.) I assert the former. If it's the latter we are in the same
situation as with github; if the CDN is gone and our origin servers
melt, it means we failed.

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Alec Warner]

On Thu, Apr 8, 2021 at 9:03 PM Alec Warner <antarus@gentoo.org> wrote:
>
> On Thu, Apr 8, 2021 at 10:22 AM Joonas Niilola <juippis@gentoo.org> wrote:
> >
> >
> >
> > On 4/8/21 7:37 PM, Alec Warner wrote:
> > >
> > > It's admittedly a grey area here. We use CDNs for various web
> > > components (packages.gentoo.org for example) and we use a CDN for
> > > distfiles.gentoo.org. Is Github simply a CDN for gentoo.git? Its an
> > > open question we have discussed on the gentoo-nfp list.
> > >
> > > In general I'm not really sold on the benefits of git as a replication
> > > protocol; while I dislike running a global rsync network the
> > > maintenance of the network is basically nil from infra's end and so I
> > > don't feel significant pressure to move to git. Could you perhaps
> > > articulate why you think it's important for clients to move to git?
> > >
> > > -A
> > >
> >
>
> So I want to discuss two thrusts here then. One is that your argument
> below is not very convincing (because it has no data that I can use to
> verify anything you said) and the second is just the social contract;
> like we are basically saying "hey we can't make git work, so we are
> going to use a non-free solution" and is that OK; I happen to think it
> is not, but see more below.
>
> > It provides much better user experience with continuously faster
> > sync-times. Also there's error posts frequently in the forums when using
> > rsync, even recently.
>
> I don't want to dig too deep here, but I'm looking again for more
> engineering focussed stuff. If we are going to make a technical
> argument, make a technical argument.
> "it provides a much better user experience" and "it's faster" are not
> arguments; or, they are insufficient to convince me of much. I did do
> some experimentation.
>
> For example on my box:
>  rsync takes about 5s for an up-to-date-check.
>  rsync takes about 1m for a daily-like sync (includes up-to-date
> check, incremental delivery, and GPG verification with WKD.)
>  rsync takes longer for a full sync, but I tend to use web-rsync for that task.
>  Github seems to have taken about 4s for an empty sync (e.g. up to date)
>  Github seems to have taken about 6s for a small sync (e.g. daily)
>  Github seems to have taken 20s for a full sync.
>
> My git-sync verification doesn't seem to be working (isn't it supposed
> to check tip-of-free for a sig? It errors out on me.)
>
> I'm skeptical people care deeply about how long syncing takes (60s and
> 5s are both fast enough for me; but I sync once a day or less.) I
> agree prima facie that Github is likely more reliable than rsync for
> most users as it's a better maintained product with a scalable
> interface.
>
> I also make a repo for anongit.g.o and it's very slow; probably 10-20x
> slower than github. We know we have a bunch of tuning to do on the
> git-serving side but no staff to do it.

Ah I had a bug here; anongit is:
 4s for empty update.
 5m for empty sync.
 I have not done an incremental (because I just fixed my bug.)

So I think if we can make it scale it might reach an rsync level of
performance, but we need to do the necessary tuning and buildout.

-A

>
>
> >
> > The way I see it, utilizing Github, it can already be implemented
> > world-wide (wrt rsync mirrors). And those disliking Github can still
> > keep using rsync, or pick the Gentoo-infra hosted sync-repo (until it
> > breaks). And regarding that, didn't you say you have a lot of money
> > needing to be used? ;)
>
> So two things here. One is that we should care about the social
> contract and I think bi-furcating the core parts of gentoo into free
> and non-free is a non-trivial change. If we move people to git syncing
> and github makes some changes, or goes away, or whatever...it's not
> like we have equivalent free setup; our git hosting is literally not
> up to the task of serving those users. I think this is the difference
> between the core offering (e.g. "gentoo") and the non-free software in
> the tree (the add-ons or additional functionality, or whatever.)
> Keeping that logic, we could keep rsync as the default sync method and
> tell people to use github if they want (syncing from github works
> today just fine.) I think that is different from making github the
> default git sync provider. I think this is similar in concept to say,
> having only free software by default; which is a change we made
> somewhat recently, iirc.
>
> This is less true for our CDN stuff, where we could just turn off the
> CDN and be fine[0].
>
> >
> > Now I don't know if it's actually *doable* already, or if this is one of
> > those things nobody brought up yet. That's why I made the post. (infra,
> > releng, handbook). If it *is* doable, I don't see why the defaults can't
> > be updated to use git. At some point at least, once we figure out the
> > global requirements.
> >
> > -- juippis
> >
>
> [0] This is an engineering argument, is the CDN a latency cache (make
> things fast) or a capacity cache (make it so our origin servers do not
> melt.) I assert the former. If it's the latter we are in the same
> situation as with github; if the CDN is gone and our origin servers
> melt, it means we failed.

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Rich Freeman]

On Fri, Apr 9, 2021 at 12:03 AM Alec Warner <antarus@gentoo.org> wrote:
>
> For example on my box:
>  rsync takes about 5s for an up-to-date-check.
>  rsync takes about 1m for a daily-like sync (includes up-to-date
> check, incremental delivery, and GPG verification with WKD.)
>  rsync takes longer for a full sync, but I tend to use web-rsync for that task.
>  Github seems to have taken about 4s for an empty sync (e.g. up to date)
>  Github seems to have taken about 6s for a small sync (e.g. daily)
>  Github seems to have taken 20s for a full sync.

I think that type of storage and cache is going to matter a LOT here,
as does update frequency.  A hard drive is going to perform far worse
for rsync, but probably not all that differently for git.

The issue is that rsync has to walk the entire repository to figure
out what changed (the cost of which depends on IOPS and cache state).
Git has an index in the form of the commit linked list and also the
tree content hashes.

On the other hand, git by default stores a whole lot of history that
is either a pro or a con depending on your requirements.  If you're
syncing once every few months git by default probably ends up sending
a whole bunch of intermediate stuff you don't care about, while rsync
just jumps you to the present.  (Ie, if a package is revised 5 times
in six months, rsync gets you from v1 to v5, while git sends you v2-4
and the metadata that tells you not to use them (but they're still
there in case you want to check out those commits)).

So, I think any technical comparison needs to pay a lot of attention
to how the repo is used and synced, and how it is stored, and how
stale the cache is when it is synced.

Really though I think the hosting issue is the bigger concern.

> So two things here. One is that we should care about the social
> contract and I think bi-furcating the core parts of gentoo into free
> and non-free is a non-trivial change. If we move people to git syncing
> and github makes some changes, or goes away, or whatever...it's not
> like we have equivalent free setup; our git hosting is literally not
> up to the task of serving those users.

I think hosting diversity is the much larger issue here: we have a ton
of http/rsync mirrors, and there aren't really a lot of options for
git mirroring out there.

If we were using a single CDN vendor for http or rsync to run our
entire mirror network I'd have the same concerns there.  As you say,
if github changes their TOS/whatever we'd be up the creek.  If one of
our bazillion http mirrors told infra they can't host us anymore it
wouldn't be a big deal because we have a ton of mirrors and they're
largely independent.  If we were using CloudFlare as our sole http
provider and CloudFlare decided to change their TOS or something, then
again would be up the creek.

So, I'd suggest that if we wanted to consider git as a primary
recommended syncing system, the main focus should be on a diversity of
mirroring providers.  I think that whether they run FOSS is a
nice-to-have as in the end git itself is FOSS and the protocol is what
matters there.  Just as we don't require http mirrors to run coreboot
I don't think we should care all that much which git implementation
they're running.  However, a diversity of providers would matter more.

However, for those who do think that FOSS-only is critical I'd say the
diversity angle would solve that.  If you're going to have 50 git
mirroring providers, it seems very likely that some would be FOSS
top-to-bottom.  I'm guessing that at most 2% of our http mirrors are
FOSS top-to-bottom (including firmware), but just having so many
ensures that people who care about that can do so, and those who don't
mind if the http mirror runs IIS as long as it speaks http can use
whatever they want.

-- 
Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 1884 bytes --]



On 4/9/21 7:03 AM, Alec Warner wrote:
>
> So two things here. One is that we should care about the social
> contract and I think bi-furcating the core parts of gentoo into free
> and non-free is a non-trivial change. If we move people to git syncing
> and github makes some changes, or goes away, or whatever...it's not
> like we have equivalent free setup; our git hosting is literally not
> up to the task of serving those users. I think this is the difference
> between the core offering (e.g. "gentoo") and the non-free software in
> the tree (the add-ons or additional functionality, or whatever.)
> Keeping that logic, we could keep rsync as the default sync method and
> tell people to use github if they want (syncing from github works
> today just fine.) I think that is different from making github the
> default git sync provider. I think this is similar in concept to say,
> having only free software by default; which is a change we made
> somewhat recently, iirc.
>
> This is less true for our CDN stuff, where we could just turn off the
> CDN and be fine[0].
>
>
Can we still offer Github mirror as an alternative in the handbook? And
adding a disclaimer about everything you said above. Or at least provide
a link to wiki page how to switch into git-syncing, somewhere in the
"Finalizing" section or "Portage introduction" perhaps?

If Github decides to "go away" quite many distributions will be far more
screwed, as some host their whole infrastructure there. At least Gentoo
has a plan B. And/If Github somehow just targets Gentoo removing our
repos, I'm sure it'll hit enough headlines to reach the users, and
they'll understand.

In the end, we're doing this for our users. I'm sure many people will
find the switch to git-syncing a treat, so the alternative should be
advertised more. (/ be more visible)

-- juippis



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1683 bytes --]

On 2021-04-11 08:26, Joonas Niilola wrote:
> Can we still offer Github mirror as an alternative in the handbook? And
> adding a disclaimer about everything you said above. Or at least provide
> a link to wiki page how to switch into git-syncing, somewhere in the
> "Finalizing" section or "Portage introduction" perhaps?

No or only if we can do that by providing a Gentoo-controlled DNS name 
pointing to GitHub (or any other service not controlled by Gentoo) but I 
don't know if this is possible with git/Github at all.

However, telling people in official documentation to use something we 
don't control will cause major problems in case we have to take actions. 
That you cannot think about any possible problem at the moment ('if 
Github decides to "go away" quite many distributions will be far more
screwed') is a very weak argument from my POV.

Imagine there will be another security incident and we will lose access 
to our GitHub mirror and we won't be able to sort the issue in a timely 
manner...

We should be prepared.

And I think we are only discussion about GitHub because some of us 
aren't always happy with the state/reliability of our infrastructure. 
But it doesn't help to ignore the root problem and move instead to third 
parties. If we want to be a real, serious, distribution with own social 
contract and not just a random project which will show up and disappear 
we should be able to run our own infrastructure in a way which makes us 
proud without the need to talk about any third party services.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On Thu, 8 Apr 2021 20:22:25 +0300 Joonas Niilola wrote:
> 
> 
> On 4/8/21 7:37 PM, Alec Warner wrote:
> >
> > It's admittedly a grey area here. We use CDNs for various web
> > components (packages.gentoo.org for example) and we use a CDN for
> > distfiles.gentoo.org. Is Github simply a CDN for gentoo.git? Its an
> > open question we have discussed on the gentoo-nfp list.
> >
> > In general I'm not really sold on the benefits of git as a replication
> > protocol; while I dislike running a global rsync network the
> > maintenance of the network is basically nil from infra's end and so I
> > don't feel significant pressure to move to git. Could you perhaps
> > articulate why you think it's important for clients to move to git?
> >
> > -A
> >
> 
> It provides much better user experience with continuously faster
> sync-times. Also there's error posts frequently in the forums when using
> rsync, even recently.

Only if you have fast and reliable uplink. Try to terminate sync
connection and resume in cycle. Rsync will do the job and recover,
so users will be able to sync on poor connection; git will start
over again and again, and again… Git can't continue failed
transfer, it will restart it from scratch. Second try will be
likely faster due to server-side cache, but a bulk transfer itself
can't be resumed, only repeated.

Try to fetch historical git using git clone by the way.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 908 bytes --]



On 4/10/21 11:26 PM, Andrew Savchenko wrote:
>
> Only if you have fast and reliable uplink. Try to terminate sync
> connection and resume in cycle. Rsync will do the job and recover,
> so users will be able to sync on poor connection; git will start
> over again and again, and again… Git can't continue failed
> transfer, it will restart it from scratch. Second try will be
> likely faster due to server-side cache, but a bulk transfer itself
> can't be resumed, only repeated.
I did that, and now I'm banned from using rsync at all. :(
(there seems to be some limit how many times you even can call rsync per
day)

> Try to fetch historical git using git clone by the way.
At least with git it's possible. I'm not aware how I can check/change
the repo state, like with git checkout, when using rsync. But I'm not
super familiar with rsync, so it might be possible?

-- juippis



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]