Subject: Re: Index format v5

From: Thomas Gummerer <[email-masked]>
Date: Thu, 10 May 2012 08:53:03 +0200

On 05/08, Nguyen Thai Ngoc Duy wrote:
> Sorry I replied too fast.
> 
> On Tue, May 8, 2012 at 9:25 PM, Nguyen Thai Ngoc Duy <[email-masked]> wrote:
> > On Tue, May 8, 2012 at 9:11 PM, Thomas Gummerer <[email-masked]> wrote:
> >>> * "160-bit object name for the object that would result from writing
> >>>   this span of index as a tree."  Is this always valid?
> >>
> >> No, this is only valid if the entry count is not -1. It's clarified
> >> now.
> >
> > ..and..
> >
> >> The entry_count in the index is only valid, if the cache-tree is valid,
> >> which is not always the case.
> >
> > I think your trees are the cache-trees already. For invalid
> > cache-trees, you can just use all-zero sha-1 as the indicator. Then
> > entry_count can go away.

How is it a cache-tree already? The subtree is covered, but the 
entry_count is calculated recursively, while nfiles only keeps track of
the files directly in the directory, which is used for bisectability.

> Furthermore, in directory entry format:
> 
>   The last 24 bytes (4-byte number of entries + 160-bit object name) are
>     for the cache tree. An entry can be in an invalidated state which is
>     represented by having -1 in the entry_count field. If an entry is in
>     invalidated state, the next entry will begin after the number of
>     subtrees, and the 160-bit object name is dropped.
> 
> Dropping objname out of invalid (cache-)trees is a bad idea. When you
> generate tree objects (aka cache_tree_update), you'll need objname
> field again, which means structure change and directory entry rewrite.
> If objname is always there, you can just overwrite objname with new
> value. Though this may bring race condition issue back to directory
> entries. The same approach on file entries might be reused.

Yes you're right, at least the field for the object name (even if 0)
should always be there.