"H. Peter Anvin" <hpa@zytor.com> wrote:I have started to think about this more myself, not just for POST put also for some form of GET that can return an efficient pack, rather than making the client walk the object chains itself. Have you looked at the Mecurial wire protocol? It runs over HTTP and uses a relatively efficient means of deciding where to cut the transfer at. http://www.selenic.com/mercurial/wiki/index.cgi/WireProtocol Most of their smarts are in the branches() and between() operations. Unfortunately this documentation isn't very complete and/or there are some simplifications that the Mecurial team took due to their repository format not initially supporting multiple branches like the Git format does. Well, over git:// (or any protocol that wraps git:// like ssh) we assume a full-duplex channel. Some proxy systems are able to do such a channel. HTTP however does not offer it. No, the git:// protocol implementation in fetch-pack/upload-pack runs more efficient than that by keeping a sliding window of stuff that is in-flight. Its I guess two async RPCs running in parallel, but from the client and server perspective both RPCs go into the same computation. HTTP POST is actually trivial if you don't want to support the new tell-me-more extension that was added to git-push. Hell, I could write the CGI in a few minutes I think. Its really just a small wrapper around git-receive-pack. What's a bitch is the efficient fetch, and getting tell-me-more to work on push. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| David Miller | Re: Slow DOWN, please!!! |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jan Engelhardt | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
