Re: "git-send-pack"

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 30, 2005, 20:52 UTC
Message-ID: <Pine.LNX.4.58.0506301344070.14331@ppc970.osdl.org>
In-Reply-To: <42C454B2.6090307@zytor.com>

On Thu, 30 Jun 2005, H. Peter Anvin wrote:

Show 5 quoted lines

> 
> 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.

No, it _is_ a constant factor even in number of files, if you just keep the pack objects around without re-packing them.

Basically, you'd get one new pack-file every time I push. That's better than getting <n> "raw object" files (where <n> can be anything from just a couple to several thousand, depending on whether I had pulled things), but it's still just a constant factor on both number of files and size of files.

Now, you could re-pack the objects every once in a while: it would force a whole new "epoch", of course and then the mirrorers would have to fetch the whole repacked file, but that might be fine. Especially if you stop re-packing after you've hit a certain size (say, a couple of megs), and then start on the next pack.

> 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.

Actually, it won't be "quick" - it will have to read the whole file and do it's hash window thing.

You _could_ append the pack-files into one single "superpack" file (since you can figure out where the pack boundaries are), but it would be extremely big after a while, and rsync would spend all its time doing over the hash window. You'd definitely be better off with re-packing.

		Linus