All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Jeff King <peff@peff.net>,
	git@vger.kernel.org
Subject: Re: RFC: Flat directory for notes, or fan-out?  Both!
Date: Tue, 10 Feb 2009 08:48:09 -0800	[thread overview]
Message-ID: <20090210164809.GO30949@spearce.org> (raw)
In-Reply-To: <7vprhqnv0c.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:
> 
> I could do a revert on 'master' if it is really needed, but I found that
> the above reasoning is a bit troublesome.  The thing is, if a tree to hold
> the notes would be huge to be unmanageable, then it would still be huge to
> be unmanageable if you split it into 256 pieces.
> 
> I'd rather prefer to see us first try to find a way to optimze the tree
> parser.  Maybe packv4 or Linus's binary search (which IIRC you declared
> would not work --- I recall I once thought about it myself but I do not
> recall what my conclusions were) play a role in it.

packv4 as proposed wouldn't help a notes tree.  It relied on the fact
that we'd have no more than 64k unique file names in a repository,
and any name which overflowed that 64k limit would force its tree
to be a canonical format tree, which is what we are trying to
avoid here.

-- 
Shawn.

  reply	other threads:[~2009-02-10 16:49 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-09 21:12 RFC: Flat directory for notes, or fan-out? Both! Johannes Schindelin
2009-02-10  7:58 ` Boyd Stephen Smith Jr.
2009-02-10 13:16   ` Jeff King
2009-02-11  1:58     ` Boyd Stephen Smith Jr.
2009-02-11  2:35       ` Linus Torvalds
2009-02-11  3:30         ` Sam Vilain
2009-02-11  3:54           ` Linus Torvalds
2009-02-11  5:05             ` Sam Vilain
2009-02-11 12:35               ` Johannes Schindelin
2009-02-10 12:18 ` Jeff King
2009-02-10 12:59   ` Johannes Schindelin
2009-02-10 13:10     ` Jeff King
2009-02-10 13:32       ` Johannes Schindelin
2009-02-10 15:58         ` Junio C Hamano
2009-02-10 16:48           ` Shawn O. Pearce [this message]
2009-02-10 16:48           ` Johannes Schindelin
2009-02-10 16:56             ` Shawn O. Pearce
2009-02-10 17:31               ` Johannes Schindelin
2009-02-10 18:35               ` Junio C Hamano
2009-02-10 19:09                 ` Shawn O. Pearce
2009-02-10 21:10                 ` Johannes Schindelin
2009-02-10 22:16                   ` Thomas Rast
2009-02-10 22:26                     ` Thomas Rast
2009-02-10 22:32                     ` Junio C Hamano
2009-02-11 20:02                   ` Jeff King
2009-02-11 20:57                     ` Johannes Schindelin
2009-02-11 21:16                       ` Junio C Hamano
2009-02-11 23:05                         ` Johannes Schindelin
2009-02-10 16:44         ` Shawn O. Pearce
2009-02-10 17:09           ` Johannes Schindelin
2009-02-10 17:17             ` Shawn O. Pearce
2009-02-11  3:19           ` Sam Vilain
2009-02-11  1:14 ` Sam Vilain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090210164809.GO30949@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.