From: H. Peter Anvin Date: Thu, 30 Jun 2005 20:23:14 GMT Subject: Re: "git-send-pack" Message-ID: <42C454B2.6090307@zytor.com> In-Reply-To: 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