Re: filesystem changes

Jim Blandy wrote:

> No, you're missing my point. The idea is to store all revisions of
> all directories in a single table. Using the revision as part of the
> key allows successive revisions of the same directory to share
> structure.
>
> For example, if we have a directory with the following revisions:
>
> 10.1: foo->12.4 bar->13.6 baz->14.7
> 10.2: foo->12.5 bar->13.6 baz->14.7
> 10.3: foo->12.5 bar->13.6 baz->14.8
>
> then that would be represented by the following entries in the table:
>
> 10 foo 1 -> 12.4
> 10 bar 1 -> 13.6
> 10 baz 1 -> 14.7
> 10 foo 2 -> 12.5
> 10 baz 3 -> 14.8
>
> To find an entry E in a node N, node revision R, you search for N E x,
> where x is the largest x <= R. So searching for "bar" in node 10.3
> probes for "10 bar x", largest x <= R, which is "10 bar 1", which is
> 13.6.
>
> So node revisions two and three each share two table entries with the
> previous node revision.

Doh. Communication failure again: node revisions vs. filesystem revisions.

We'll have to change these names, this is the third time we've been
bitten ... filesystem avatars, maybe? Node incarnations? :-)

> Is there something broken about this?

Not that I can see -- of course, this is exactly the same scheme I was
proposing, except that the pieces of the node revision ID are laid out
differently in the key.

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/