git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Edelen <sirnot@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Nicolas Pitre <nico@cam.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Sam Vilain <sam@vilain.net>,
	Michael J Gruber <git@drmicha.warpmail.net>,
	Jeff King <peff@peff.net>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Andreas Ericsson <exon@op5.se>,
	Christian Couder <christian@couder.net>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 4/6 (v2)] administrative functions for rev-cache, and  start of integration into git
Date: Tue, 11 Aug 2009 11:49:49 +0200	[thread overview]
Message-ID: <c77435a80908110249y1ce82dd4n77b3b81e532daeea@mail.gmail.com> (raw)
In-Reply-To: <7vtz0g7s1p.fsf@alter.siamese.dyndns.org>

> It is unclear which "size" this field refers to without comment.
>
> I do not know if this change is justifiable.  We (mostly Linus) spent
> considerble effort to shrink the memory footprint of struct commit (and
> struct object in general) exactly because revision traversal needs to
> inspect tons of them.

I originally added a `size` field to objects, a `unique` field to
commits and `name` ones to blobs/trees.  This was (I reasoned) partly
for applications to take fuller advantage of rev-cache's abilities,
but largely to ease re-use of its information in slice regeneration.

However, in retrospect I think you're probably right.  Not only do I
not really need to load the information into memory to re-use it, but
applications using rev-cache would probably have sufficiently
specialized needs to warrant direct access.  In light of this I've
rewritten the fuse command to re-use data directly from the slice,
rather than requiring it to be loaded into memory first (hence
eliminating the all those extra fields).  Furthermore I'll put all the
(renamed) structures and definitions in a seperate header, to allow
easy direct access to slices by third-parties.

> Looks vaguely familiar.
>
> The configuration parser already knows about these size suffixes when told
> to read "int".  Can't that code, e.g. git_parse_ulong(), be reused here?

You're also right here.  I wrote it fast and hadn't checked if git had
already implemented it.  I've changed it to use git_parse_ulong().

Sorry I haven't uploaded anything yet.  I keep seeing new things that
could updated or revised; so far I've
 - rewritten and added much to the documentation
 - added support for an alternates-like mechanism
 - changed --noobjects to --no-objects
 - changed init_rci to init_rev_cache_info
 - modified make_cache_slice to return actual start/end commits
 - changed coagulate_ to fuse_
 - added an (admittedly crude) escape plan in case of obscenely large
merges/branches
 - cleaned up path generation
 - replace parse_size with git_parse_ulong
 - rewritten fuse to reuse objects verbatim, rather than via memory access

And on my todo list I've still got things such as renaming all the
structures/definitions, adding a more portable _ondisk version of
bitfield'ed structs and obviously cleanup the patchset (eliminating
fixes of earlier patches, etc.).

I hope to get everything finished in the next couple days, and upload
a v3 by friday at the latest.

 - Nick

  reply	other threads:[~2009-08-11 12:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-08  7:31 [PATCH 4/6 (v2)] administrative functions for rev-cache, and start of integration into git Nick Edelen
2009-08-09 18:36 ` Junio C Hamano
2009-08-11  9:49   ` Nick Edelen [this message]
2009-08-16 22:42 ` Nick Edelen

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=c77435a80908110249y1ce82dd4n77b3b81e532daeea@mail.gmail.com \
    --to=sirnot@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=christian@couder.net \
    --cc=exon@op5.se \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=nico@cam.org \
    --cc=peff@peff.net \
    --cc=sam@vilain.net \
    --cc=spearce@spearce.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).