Re: git-daemon on NSLU2

From: Jakub Narebski <jnareb@gmail.com>
Date: Aug 27, 2007, 00:14 UTC
Message-ID: <200708270214.28652.jnareb@gmail.com>
In-Reply-To: <20070826093331.GC30474@coredump.intra.peff.net>

On Sun, Aug 26, 2007, Jeff King wrote:

Show 22 quoted lines

> On Sat, Aug 25, 2007 at 11:44:07AM -0400, Jon Smirl wrote:
> 
>> A very simple solution is to sendfile() existing packs if they contain
>> any objects that the client wants and let the client deal with the
>> unwanted objects. Yes this does send extra traffic over the net, but
>> the only group significantly impacted is #2 which is the most
>> infrequent group.
>>
>> Loose objects are handled as they are currently. To optimize this
>> scheme you need to let the loose objects build up at the server and
>> then periodically sweep only the older ones into a pack. Packing the
>> entire repo into a single pack would cause recent fetches to retrieve
>> the entire pack.
> 
> I was about to write "but then 'fetch recent' clients will have to get
> the entire repo after the upstream does a 'git-repack -a -d'" but you
> seem to have figured that out already.
> 
> I'm unclear: are you proposing new behavior for git-daemon in general,
> or a special mode for resource-constrained servers? If general behavior,
> are you suggesting that we never use 'git-repack -a' on repos which
> might be cloned?

I think that "reuse existing packs if sensible" idea (instead of generating always new pack) is a good one, even if at first limited to the clone case.

There are nevertheless a few complications.

1. When discussing this idea on git mailing list some time ago somebody
said that we don't need to implement "multi pack" extension (which was
at the beginning in the design, to add later, if I understand correctly),
it is enough to concatenate packs. The receiving side can then detect
boundaries between packs and split them appropriately. But is a
concatenated a proper pack? If not, then we can send concatenation of
packs only if the client (receiving side) understands it, and can split it;
it means checking for protocol extension...

2. How to detect that request is for a clone? git-clone is get all remote
heads and fetch from just received heads. But because fecthing refs and
fetching objects is separate, we cannot I think use this sequence for
detecting that we want a clone. We can use "no haves" as heuristic to
detect a clone request, but "no haves" occurs also for initial fetching of
single branch (i.e. using: git-remote; git-fetch sequence instead of
git-clone).

3. The problem with alternates mentioned by Linus is not much a problem,
as we can simply consider packs from the alternate repository/repositories.
For example if we use single alternate, we would send concatenation of
packs from this repository, and from alternate (and pack of loose objects
from this repository).

We would probably want to have some heuristic (besides configuring git-daemon) to choose between reusing existing packs (and sending them concatenated), and generating a pack for sending. Note that for dumb transports we have the opposite problem and opposite idea: we always send full packs for dumb transports; the idea was to use range downloading (available at least for http and ftp protocols) to download only needed fragments of packs. Perhaps if some % of pack (number of objects in the pack or size of pack) is to be send then we reuse the pack, and remove objects in the pack from consideration. No idea of how to implement that, though. Or if number of objects in pack to be send crosses some threshold, or generating pack/doing reachability analysis takes to loong, then reuse existing packs.

Or you can wait fro the GitTorrent protocol to be implemented, or implement it yourself... ;-)

-- 
Jakub Narebski
Poland