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

[Chris Mason]

On Wed, 2004-01-07 at 00:38, Miles Bader wrote:
> Chris Mason <address@hidden> writes:
> > Yes, there's a space wasting issue, but arch has that in general with id
> > files already.
> 
> ... unless you use taglines.

The reverse mapping is only created for explicit ids.  This is because I
wanted to limit the scope of the code somewhat.

> 
> > > Why not just have one big `signature database' (preferably not `big'
> > > in reality of course :-) that includes both inode and pathname
> > > information, and make sure it's always kept as up to date as
> > > possible by all operations?
> >
> > I guess I went into this assuming there was a reason arch didn't already
> > use an embedded database for ids (Tom's personal taste?).  The reverse
> > mapping is really just a database style index into the source tree. 
> > There's not much semantic difference between having id files and all
> > relevant info stored in a database.
> 
> There's a big difference; a `signature database' like I'm talking about
> is just an optimization:
> 
>   * It's allowed to be out-of-date or non-exstant -- and you have to
>     deal with these cases.  However, for non-whole-tree operations like
>     changeset application, this sort of up-to-date verification is still
>     only per-file, so much, much faster than statting the whole tree
> 
It's allowed to be non-existent, but can't be out of date for anything
except inode contents (permissions, times, etc).  In order for the apply
changeset code to trust the reverse mapping (skipping the whole tree
scan), it has to be correct.

>   * It's `central' (and perhaps monolithic, e.g., a single file or
>     indexed db file), and so is a lot easier to grok and update
>     efficiently, but doesn't have the automatically-sticks-
>     close-to-the-source properties of taglines or explicit tags.
> 
>   * Contains lots of useful information (inode contents) that aren't
>     strictly speaking part of the id-tag, and is at best `advisory'.
> 
> I.e., just like inode-sigs today, or indeed like your reverse database.
> 
Sure.  I do agree it could replace both the inode sigs and the reverse
mapping.  My goal was to keep the patch within the spirit of the rest of
arch.  So my first implementation was the files.

For now I'd have to leave actually coding the id database as an exercise
for the reader, but I might be able to get to it later this month.

-chris