Re: Understanding version 4 packs

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

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.
 
> > The author_time field is not present if flags & 128 is true.
> > If flags & 128 is false, its present, and uses the same encoding
> > as commit_time.  Why is this field optional?  Because its not
> > uncommon for it to match commit_time!  ;-)
> 
> If the author time is the same as the commit time, most of the time the 
> author is the same as the committer too, no? So the field should be 
> conditional not for the author_time, but for the combination, no?

Excellent observation.  I'll make that change at the same time that I
fix the meaning of flags & 128 to mean "more data follows".  Thanks!

-- 
Shawn.