Re: support for large packs and 64-bit offsets
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Apr 9, 2007, 19:53 UTC
- Message-ID
- <20070409195322.GB5436@spearce.org>
- In-Reply-To
- <7vtzvpz5tu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
Show 18 quoted lines
> "Shawn O. Pearce" <spearce@spearce.org> writes: > > > Nicolas Pitre <nico@cam.org> wrote: > > ... > > 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. > > If we really care about older dumb clients, one option is to > generate not .idx but .idx2, and have a corresponding .idx only > to support them. But at that point, it's probably cleaner to > have an explicit option to produce .idx file of a particular > version, and tell people to pack public repositories they expect > older dumb clients to access with that option to keep things > backward compatible.
Sure, fine. But I think you missed my point above - right now if we move the SHA-1 table out of the .idx file I'm not sure we know how to support the dumb clients *at all*. Even if they understand the latest-and-greatest file formats...
-- Shawn.