Re: Smart fetch via HTTP?

On Fri, May 18, 2007 at 10:01:52 +0100, Johannes Schindelin wrote:

Hi,

On Thu, 17 May 2007, Jan Hudec wrote:

quoted

On Thu, May 17, 2007 at 10:41:37 -0400, Nicolas Pitre wrote:

quoted

And if you have 1) the permission and 2) the CPU power to execute such 
a cgi on the server and obviously 3) the knowledge to set it up 
properly, then why aren't you running the Git daemon in the first 
place?  After all, they both boil down to running git-pack-objects and 
sending out the result.  I don't think such a solution really buys 
much.

Yes, it does. I had 2 accounts where I could run CGI, but not separate 
server, at university while I studied and now I can get the same on 
friend's server. Neither of them would probably be ok for serving larger 
busy git repository, but something smaller accessed by several people is 
OK. I think this is quite common for university students.

1) This has nothing to do with the way the repo is served, but how much 
you advertise it. The load will not be lower, just because you use a CGI 
script.

That won't. But that was never the purpose of "smart cgi". The purpose was to
minimize the bandwidth usage (and connectivity is still not so cheap that
you'd not care) while still working over http either because the users need
to access it from behind firewall or because administrator is not willing to
set up git-daemon for you, while CGI you can run yourself.

2) you say yourself that git-daemon would have less impact on the load:

NO, I didn't -- at least not in the paragraph below.

In the below paragraph I said, that *network* use will never be as good with
*dumb* solution, as it can be with smart solution, no matter whether it is
over special protocol or HTTP.

---

Of course it would be less efficient in both CPU and network load, because
there is the overhead of the web server and overhead of the http headers.

Actually I like the ranges solution. If accompanied with repack stategy that
does not pack everything together, but instead creates packs of limited
number of objects -- so that the indices don't exceed configurable size, say
64kB -- could not so much less efficient for the network and have the
advantage of working without ability to execute CGI.

quoted

quoted

[...]

Et voilà.  Oh, and of course update your local refs from the 
remote's.

Actually there is nothing really complex in the above operations. And 
with this the server side remains really simple with no special setup 
nor extra load beyond the simple serving of file content.

On the other hand the amount of data transfered is larger, than with the 
git server approach, because at least the indices have to be transfered 
in entirety.

-- 
						 Jan 'Bulb' Hudec [off-list ref]