Bob, I can't really speak to what you've said. I only note that https:// from Savannah is quite slow, whereas if I https:// clone a Github repo, it's quite fast. I suspect that Github is what has set my expectatations.
For day-to-day work, obviously, I use ssh. But only a few people in the world have ssh access to the gawk repo; the rest use https:// or git://. I know that Github disabled git:// access some years ago, I think out of security concerns --- so out of habit I always use https:// for Git repos. Hmmm... > $ time git clone https://git.savannah.gnu.org/git/gawk.git I don't think I knew about this option. I will update the gawk doc with this URL. Thanks, Arnold Bob Proulx <b...@proulx.com> wrote: > arn...@skeeve.com wrote: > > Things are better at the moment (it's ~ 2:30 AM east coast time). > > But... Although an https clone no longer pegs my CPU at 100%, it still > > sucks: > > > > $ time git clone https://git.savannah.gnu.org/r/gawk.git > > Cloning into 'gawk'... > > Fetching objects: 61396, done. > > > > real 11m34.265s > > user 0m39.351s > > sys 0m6.825s > > There are two problems with the above. One is that of course the > https:// protocol has more overhead and must compete with all of the > abuse agents that are always hammering on the web service. It's > probably never going to be as fast as using the ssh:// protocol. > > But two is that the above is using the raw web file access URL. Why? > That's never going to be as efficient as the git smart http protocol. > That's intentionally choosing the worst possible source to clone. > > Example from my system in Colorado which should be a fair test going > across the net from a distance using the git smart http protocol. > > rwp@madness:/tmp/junk$ time git clone > https://git.savannah.gnu.org/git/gawk.git > Cloning into 'gawk'... > remote: Counting objects: 61396, done. > remote: Compressing objects: 100% (14478/14478), done. > remote: Total 61396 (delta 48459), reused 58396 (delta 46267) > Receiving objects: 100% (61396/61396), 66.18 MiB | 2.61 MiB/s, done. > Resolving deltas: 100% (48459/48459), done. > > real 1m11.502s > user 0m41.194s > sys 0m0.970s > > I have sometimes thought that we should remove the /r/ raw access > path. But as you know breaking something that people are using upsets > them because it breaks something they were working using. > > At one time I believe the /r/ path was needed for people behind > restrictive firewalls and broken http proxies to be able access the > repository regardless of their bad environments. During the http:// > days. But now with https:// use one can't proxy through and that > already blocks bad corporate http proxies. And bad firewalls already > are unhappy that they can't see into encrypted https connections. > Which makes this very odd niche access method pretty much obsolete. > > Bob
