savannah-hackers-public
[Top][All Lists]
Advanced

[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.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]