From: david@lang.hm
Date: Sun, 05 Apr 2009 23:20:07 GMT
Subject: Re: Performance issue: initial git clone causes massive repack
Message-ID: <alpine.DEB.1.10.0904051613420.6245@asgard.lang.hm>
In-Reply-To: <20090405225954.GA18730@vidovic>

On Mon, 6 Apr 2009, Nicolas Sebrecht wrote:

> On Sun, Apr 05, 2009 at 02:28:35PM -0700, david@lang.hm wrote:
>
>> guys, back off a little on telling the gentoo people to change.
>
> Don't blame Git people, please. I currently am the only one here to
> discuss that way and see a painful work coming at Gentoo.
> Git people didn't discuss around thoses issues.
>
>>                                                                 the
>> kernel developers don't split th kernel into 'core' 'drivers' etc pieces
>> just because some people only work on one area.
>
> And you might notice that they don't provide a CVS access and actually
> don't work around an unique shared repo. Also, you might notice that
> keeping the history clean to assure the work on the kernel easier is not
> an elementary issue.

these issues are completely seperate from the issue that the initial 
poster asked about, which is that when someone tries to do a clone of the 
repository the system wastes a lot of time creating a new pack.

the kernel has a central public repo, they could run the cvs server on 
that and still keep the rest of the kernel development exactly the way it 
is.

if they are currently planning for one central repo with everyone pushing 
to it, I expect that they will change their workflow as they get used to 
git, but that isn't going to address the problem in the tool.

>> just because some people only work on one area. I see the gentoo desire
>> to keep things in one repo as being something very similar.
>
> That's why I think the gentoo desire is not very clean (don't be
> affected). What I see is that in one hand you want a DSCM and on the
> other hand you want to keep a central shared repo.

don't worry about this part of things, worry about why the server wastes 
so many resources.

if this is really what's happening, other projects will suffer as well 
(including the kernel, which has a very distributed workflow)

>> the problem here is a real one, if you have a large repo, git send-pack
>> will always generate a new pack, even if it doesn't need to (with the
>> extreme case being the the repo is fully packed)
>
> What about the rsync solution given in this thread?

that may be a work-around for a situation where git just doesn't work, but 
how do they prevent users from killing their server by trying to do a 
normal git clone?

Daivd Lang