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

["Shawn O. Pearce" <spearce@spearce.org>]

Nicolas Pitre <nico@cam.org> wrote:
> 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.