From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: RFC: Flat directory for notes, or fan-out? Both! Date: Tue, 10 Feb 2009 07:58:59 -0800 Message-ID: <7vprhqnv0c.fsf@gitster.siamese.dyndns.org> References: <20090210121833.GC15491@coredump.intra.peff.net> <20090210131029.GC17305@coredump.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeff King , git@vger.kernel.org, spearce@spearce.org To: Johannes Schindelin X-From: git-owner@vger.kernel.org Tue Feb 10 17:00:40 2009 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1LWv2L-00054y-EK for gcvg-git-2@gmane.org; Tue, 10 Feb 2009 17:00:37 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753896AbZBJP7K (ORCPT ); Tue, 10 Feb 2009 10:59:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753883AbZBJP7I (ORCPT ); Tue, 10 Feb 2009 10:59:08 -0500 Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:52237 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753857AbZBJP7G (ORCPT ); Tue, 10 Feb 2009 10:59:06 -0500 Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id B1FD12AD71; Tue, 10 Feb 2009 10:59:05 -0500 (EST) Received: from pobox.com (unknown [68.225.240.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id CB9422AD68; Tue, 10 Feb 2009 10:59:00 -0500 (EST) User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Pobox-Relay-ID: BE5AE440-F78B-11DD-82D2-6F7C8D1D4FD0-77302942!a-sasl-quonix.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Johannes Schindelin writes: >> OK. I think if you are seeing performance benefits from a 2-character >> fanout, then we should standardize on that (do you have new performance >> numbers somewhere?). > > The thing is: Shawn is correct when he says that a tree object to hold the > notes of all commits (which is not an unlikely scenario if you are > thinking about corporate processes) would be huge. > >> The notes implementation is now in master. If it's about to change in an >> incompatible way, how do you want to handle it? I'm wary of a quick >> patch to change the format this late in the release cycle. We could hold >> it back from 1.6.2. Alternatively, we could let it release with a "this >> is probably going to change" warning. >> >> I think I favor holding it back, but I am not picky. > > Yes, I am also in favor of holding it back. 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.