Re: "git-send-pack"

["H. Peter Anvin" <hpa@zytor.com>]

Linus Torvalds wrote:
> 
> It won't _really_ solve the problem, since the pushed pack objects will
> grow at a proportional rate to the current objects - it's just a constant
> factor (admittedly a potentially fairly _big_ constant factor)  
> improvement both in size and in number of files.
> 

If I've understood this correctly, it's not a constant factor 
improvement in the number of files (in the size, yes); it's changing it 
from O(t*c) to O(t) where t is number of trees and c is number of 
changesets.  That's key.

The problem we're having (on kernel.org) right now is that there isn't a 
hierarchial time stamp in Unix, so we have to compare on a file-by-file 
level.  rsync is quite good at discovering an invariant beginning of a 
file, but when it comes to a mass of files it has to compare the stamps 
on each and every one, each time.  It will only descend into a single 
file, however, if that file has had its timestamp changed.

For the purposes of rsync, storing the objects in a single append-only 
file would be a very efficient method, since the rsync algorithm will 
quickly discover an invariant head and only transmit the tail.  It's not 
ideal, and having something git-aware would be better, but I think it's 
really would be nice to have something which also plays well with rsync. 
  There is a *lot* of infrastructure in rsync which is actually hard to 
replicate with another tool (including the server architecture); in many 
ways it would be easier to convince the rsync developers to create a 
plugin architecture and re-use all that code rather than developing an 
equivalent tool from scratch.

	-hpa