Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes

Hi,

On Fri, 28 Aug 2009, Johan Herland wrote:

On Thursday 27 August 2009, Junio C Hamano wrote:

quoted

"Shawn O. Pearce" [off-list ref] writes:

quoted

Yea, it was me.  I still think it might be a useful idea, since it 
allows you better density of loading notes when parsing the recent 
commits.  In theory the last 256 commits can easly be in each of the 
2/ fanout buckets, making 2/38 pointless for reducing the search 
space.  Commit date on the other hand can probably force all of them 
into the same bucket, making it easy to have the last 256 commits in 
cache, from a single bucket.

But I thought you shot it down, by saying that we also wanted to 
support notes on blobs.  I happen to see no value in a note on a 
blob, a blob alone doesn't make much sense without at least an 
annotated tag or commit to provide it some named context, and the 
latter two have dates.

Yeah, and in this thread everybody seems to be talking about commits 
so I think it is fine to limit notes only to commits.

Agreed. I'm starting to come around to the idea of storing them in 
subtrees based on commit dates. For one, you don't have multiple notes 
for one commit in the same notes tree. Also, the common-case access 
pattern seems tempting.

Dscho: Were there other problems with the date-based approach other than 
not supporting notes on trees and blobs?

It emphasized an implementation detail too much for my liking.

And I would rather have some flexibility in the code as to _when_ it fans 
out and when not.

So I can easily imagine a full repository which has only, say, 5 notes.  
Why not have a single tree for all of those?

And I can easily imagine a repository that has a daily note generated by 
an automatic build, and no other notes.  The date-based fan-out just 
wastes our time here, and even hurts performance.

Ciao,
Dscho