Re: "git-send-pack"
- From
- H. Peter Anvin <hpa@zytor.com>
- Date
- Jun 30, 2005, 20:23 UTC
- Message-ID
- <42C454B2.6090307@zytor.com>
- In-Reply-To
- <Pine.LNX.4.58.0506301302410.14331@ppc970.osdl.org>
Linus Torvalds wrote:
Show 6 quoted lines
> > 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