[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Savannah-hackers-public] VERY slow git response from Savannah
From: |
Leo Famulari |
Subject: |
Re: [Savannah-hackers-public] VERY slow git response from Savannah |
Date: |
Wed, 21 Feb 2018 16:09:17 -0500 |
User-agent: |
Mutt/1.9.3 (2018-01-21) |
On Wed, Feb 21, 2018 at 12:45:24PM -0700, Bob Proulx wrote:
> address@hidden wrote:
> > I would have thought most people would do 'git pull' instead of 'git clone'
> > and that pulling wouldn't be quite as intensive, but who knows...
>
> I think that these days most people do not keep persistent state. The
> cynic in me assumes they are working from their phone. Instead they
> clone a new repository, do something, then toss it away. Even for
> continuous integration systems many people do not use a local cache.
> I can't prove this but it is just my observation of the way people
> work around me in real life. This makes large projects very I/O
> intensive when things happen.
As a relative young'un with a smartphone, I can say that doing
development on my phone sounds like a bad time! I typically keep full
clones around, even for one-off things. Source code is small and
gigabytes are cheap.
> I was actually using clone generically there. But if people were
> pulling then I would have expected the processes to have finished
> quickly. But we do periodically see large repositories getting cloned
> at the same time due to project announcements all run at the same time
> and take up time. I don't know which projects were getting pulled or
> cloned since we do not log that information. But previously Emacs has
> been the cause of it becaues the repos is large (and originally was
> larger) making cloning need a lot of bandwidth. When Emacs announces
> a new release there is usually a spike. So using it as an example
> without saying that was the project this time.
I imagine there are CI systems that do full clones and then check out
the commit they want. Of course this is a big waste of bandwidth, so in
Guix we are looking into the possibility of shallow cloning for related
use cases. This may be less efficient on the server; I guess it depends
on the server implementation. Still, we favor release tarballs because
they are small and the required software is much less complex.
signature.asc
Description: PGP signature