Re: support for large packs and 64-bit offsets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 9 Apr 2007, Shawn O. Pearce wrote:

> Junio C Hamano <junkio@xxxxxxx> wrote:
> > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> > 
> > > Nicolas Pitre <nico@xxxxxxx> 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...

The table could live in both the pack and the index for those repos 
expected to be exportable through dumb protocols.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]