Re: [PATCH] Support 64-bit indexes for pack files.

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 28, 2007, 03:52 UTC
Message-ID: <20070228035248.GB5597@spearce.org>
In-Reply-To: <alpine.LRH.0.82.0702271235260.29426@xanadu.home>

Nicolas Pitre <nico@cam.org> wrote:

Show 7 quoted lines

> On Tue, 27 Feb 2007, Geert Bosch wrote:
> > For smaller packs, the I/O is all going to be buffered anyway,
> > but if we're going to have >4GB pack files, it adds a lot of real
> > I/O  and SHA1 computation for no good reason. If we get a rare chance
> > to have a new pack format, why not fix this wart at the same time?
> 
> Fair enough.

OK, so lets say that if both ends of a network transport support pack v4 then we can use pack v4. If pack v4 omits the count field from its header (because its easily derived or obtained from the index, and doesn't add any additional data protection over the SHA-1s) why not add some machine-readable sideband that can provide transfer progress?

I think we would want four values, number of objects (sent/total) and uncompressed bytes (sent/total), to send to the client.

Estimating the total uncompressed bytes is very easy in pack-objects before we start sending even the header; actually if we are reusing a majority of the objects from an existing packfile we even have a good approximation of the compressed size ready. That would give the client a reasonable progress meter; certainly better than nothing at all! ;-)

-- 
Shawn.