Jan Hudec wrote: > 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. Perhaps we could also simply tunnel git protocol over HTTP / HTTPS? > > 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. Perhaps we could use AJAX (XMLHttpRequest for communication, plain HTTP or IFRAMES for sending data) or something like this for git protocol tunneling? -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
