Re: Understanding version 4 packs

From: Nicolas Pitre <nico@cam.org>
Date: Mar 26, 2007, 01:12 UTC
Message-ID: <alpine.LFD.0.83.0703252102520.3041@xanadu.home>
In-Reply-To: <20070325203141.GA12376@spearce.org>

On Sun, 25 Mar 2007, Shawn O. Pearce wrote:

Show 21 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Sun, 25 Mar 2007, Shawn O. Pearce wrote:
> > > >
> > > > What happens to the paths, that do not have a correponding entry in the
> > > > path name table, because they are not among the 65535 most frequent
> > > > paths in the pack?
> > > 
> > > They don't appear in the table.  And any tree that uses them is
> > > forced to use the "legacy" OBJ_TREE encoding.  Which is what we
> > > have now in pack v2, and in loose objects.
> > 
> > Would it hurt too much to just make it four bytes, and avoid that issue?
> > 
> > Special cases - and *especially* special cases that are hard to trigger in 
> > the first place - equal bugs. And bugs are much much worse than trying to 
> > save a little bit of space.
> 
> Worth exploring.  When I get back to rebasing that topic onto
> Junio's tree I'll try a 4 byte index and see what kind of damage
> it does on space on large projects (Mozilla, linux-2.6, Eclipse).
> You may be right, an 8 byte record may just be worth the cost.

Maybe simply 3 bytes might be a good compromise too. I doubt a single pack is ever to contain 4G paths since it is limited to 4G _objects_ in the first place.

Another approach is to have the path index field width as the first item in such an object. This way it can be scalled as needed.

BTW Shawn there is no need to store the number of tree records at the beginning of the tree object since that can be deduced directly from the object size stored in the object header.

Nicolas