Re: [Gnu-arch-users] Re: [PATCH] arch speedups on big trees

[Chris Mason]

On Wed, 2004-01-07 at 08:42, Mark A. Flacy wrote:
> >>>>> "Miles" == Miles Bader <address@hidden> writes:
> Miles> 
> Miles> There's a big difference; a `signature database' like I'm talking about
> Miles> is just an optimization:
> Miles> 
> Miles>   * It's allowed to be out-of-date or non-exstant -- and you have to
> Miles>     deal with these cases.  However, for non-whole-tree operations like
> Miles>     changeset application, this sort of up-to-date verification is 
> still
> Miles>     only per-file, so much, much faster than statting the whole tree
> Miles> 
> Miles>   * It's `central' (and perhaps monolithic, e.g., a single file or
> Miles>     indexed db file), and so is a lot easier to grok and update
> Miles>     efficiently, but doesn't have the automatically-sticks-
> Miles>     close-to-the-source properties of taglines or explicit tags.
> 
> "Easier to update efficiently" only if you don't allow concurrent access.

If the indexed db file is located in the source tree, it has the same
concurrent access issues as the regular id files.   Instead of the
kernel handling parallel access issues the embedded database code needs
to deal with it.

They are just two different implementations of the same basic idea:
"objects in the repository have ids".  The reverse mapping in my patches
is just an index for fast id lookup, which the database file would solve
with an index of its own.

-chris