Re: What to expect after 0.99.8

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 4, 2005, 04:13 UTC
Message-ID: <Pine.LNX.4.63.0510032306190.23242@iabervon.org>
In-Reply-To: <7v1x32l0gz.fsf@assigned-by-dhcp.cox.net>

On Mon, 3 Oct 2005, Junio C Hamano wrote:

Show 15 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > The code in ssh-fetch already does parallel fetching, actually (only over 
> > one connection, but requests are sent before responses are read), so 
> > multiple requests are in progress at the same time.
> 
> This reminds me of one patch:
> 
>     From: Dan Aloni <da-x@monatomic.org>
>     Subject: [PATCH] Fix git+ssh's indefinite halts during long fetches
>     Date: Sat, 1 Oct 2005 21:39:42 +0300
>     Message-ID: <20051001183942.GA2099@localdomain>
> 
> I'd appreciate it if you had a chance to take a look at it and
> comment on it.

I think it's overly hacky; we should be able, in prefetch, to check whether we've stuffed in a lot of hashes already, and actually read an object out before requesting another; there's nothing in the fetch contract that says that an object can't become available at some random time between the start of the fetch and when it gets requested with fetch(). (In fact, I had a pack-exchange version of the ssh stuff which would notice that you have certain things and you're looking for a commit, and get a bunch of stuff you probably want as a pack before you actually ask for it, but Linus beat me on that one with send-pack/upload-pack.)

I think that a limit of 100 objects in transit is about right, because the requests for 100 objects fits well within 4K and I expect that we commonly have small enough objects that we need to queue up a relatively large number of requests to maintain streaming.

I've got a patch, which I'll send in the next email.

	-Daniel
*This .sig left intentionally blank*