Re: support for large packs and 64-bit offsets
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Apr 9, 2007, 17:43 UTC
- Message-ID
- <20070409174305.GU5436@spearce.org>
- In-Reply-To
- <alpine.LFD.0.98.0704091328130.28181@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
Show 11 quoted lines
> On Mon, 9 Apr 2007, Shawn O. Pearce wrote: > > > It is unfortunate that we are changing the index file format without > > also bringing in packv4 support at the same time. I have just been > > too swamped in useless bulls**t in day-job work to spend time on > > Git lately. > > Well... I still did index v2 with pack v4 in mind. The diference > between index v2 and v3 would be minimal. > > Pack v4 is coming along. Slowly but still coming.
I take it you are working on it alone at this point? I'd love to get back into it, but I don't think I've got the cycles for at least a couple of weeks.
Here's something we didn't think about, but that occurred to me today when reading this series: If we move the SHA-1 table out of the index and into the packfile (like we are planning) dumb commit-walkers (http-fetch) will have problems. Right now they download the indexes of every available packfile to determine if they need to download the corresponding packfile to obtain a needed object.
Moving the SHA-1 table from the index into the packfile will mean the client cannot do this `optimization'. Instead it will need to perform a byte-range request for part of the packfile to decide if it needs to fetch the remainder of that packfile; or it must download the entire packfile. Since not all HTTP servers support byte-range requests the former may not always be viable and the latter is obviously not a good idea.
-- Shawn.