Re: git over webdav: what can I do for improving http-push ?

> On Thu, Jan 03, 2008 at 20:14:09 +0100, Grégoire Barbier wrote:
>
> > I had a quick look on bzr and hg, and it seems that bzr use the easy way 
> > (walker, no optimizations)
> 
> That's not quite true -- bzr has both dumb (walker over plain HTTP) and smart
> (CGI) methods. But their CGI is really just tunelling their custom protocol
> over HTTP and that protocol will not be anywhere near what we want for git
> because of vastly different design of the storage.

> > and hg a cgi (therefore, maybe optimizations). 
> > By quick look I mean that I sniff the HTTP queries on the network during a 
> > clone. I need to look harder...
> 
> Yes, mercurial uses a CGI. But I am not sure how similar their approach is to
> anything that would make sense for git, so looking at the details might or
> might not be useful.
> 
> > BTW I never looked at the git:// protocol. Do you think that by tunneling 
> > the git protocol in a cgi (hg uses URLs of the form 
> > "/mycgi?cmd=mycommand&...", therefore I think "tunnel" is not a bad 
> > word...) the performance would be good?
> 
> It would be pretty hard to tunnel it and it would loose all it's nice
> properties. The git protocol, for pull, basically works like this:
> 
>  - server sends a list of it's refs
>  - client tells server which ones it wants
>  - client starts listing revisions it has, newest to oldest
>  - server tells client whenever it finds common ancestor with one of the
>    heads desired
>  - client restarts the listing from next ref
>  - server starts sending the data when client runs out of refs to list
> 
> The main point about the protocol is, that the client is listing the refs, as
> fast as it can and server will stop it when it sees a revision it knows.
> Therefore there will only be one round-trip to discover each common ancestor.
> 
> However, you can't do this over HTTP, because response won't be started until
> the request is received. You could be sending a lot of smallish requests and
> quick, often empty, responses to them. However, that will waste a lot of
> bandwidth (because of the HTTP overhead) and loose much of the speed anyway.
> Also the HTTP protocol is stateless, but this is inherently stateful, so you
> would have to work that around somehow too. Therefore a different approach is
> preferable on HTTP.