Re: Mozilla .git tree

From: Junio C Hamano <junkio@cox.net>
To: Shawn Pearce <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: Mozilla .git tree
Date: Fri, 01 Sep 2006 21:01:49 -0700	[thread overview]
Message-ID: <7v8xl23oia.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20060902011950.GB24234@spearce.org> (Shawn Pearce's message of "Fri, 1 Sep 2006 21:19:50 -0400")

Shawn Pearce <spearce@spearce.org> writes:

> What I did in fast-import was give inflate whatever was left in
> the current mapping; then if I got a Z_OK or Z_BUF_ERROR back from
> inflate I move the mapping to the next 128 MiB chunk and reset my
> z_stream's next_in/avail_in accordingly, then recall inflate.

Makes sense.

> But having the length or ending offset in the index will help with
> copying the object during a repack as well as prevent us from needing
> to guess during accesses.

Actually pack-objects already builds the reverse index without
the help from the updated .idx file format, so while having it
pre-built in .idx may help, it is not necessary for it.  With
your "feed until the end of the current window and if we need
more map in the next window" logic, we do not even need to know
the length of each entry at runtime either.

So I am inclined to chuck the previous patch that records the
next object number in each entry.  We could keep the 64-bit
offset, which would make an entry to be 28-byte instead of
32-byte.

-- 
VGER BF report: U 0.5