Re: Filesystem structure question

Greg Hudson wrote:

>> With the current scheme, the version tree of a node is indexed. You
>> can find whole branches, tips, branchpoints, etc. with a single
>> query into the "nodes" table.
>
>
> Sure, but what needs to do this?

I'd think getting to the tip of any branch is the first thing you need
to do for updates and checkouts.

>> With your scheme, all that information would have to be storead
>> explicitly in the tables with pointers between nodes. We'd have to
>> maintain the version tree by hand, opening a door for consistency
>> problems.
>
>
> Why would that information have to be stored with pointers between
> nodes,

How else are you going to maintain the version graph, then?

> and why would we have to maintain the version tree by hand?

You'd need to store informatin about successors and predecessors in the
node data. That means changing two records, not one, for every new
vesion added.

> What consistency problems would exist which don't exist in the current
> model?

Right now, the consistency of the version tree depends on the
correctness of one function -- the key comparator for the "nodes" table.

>> It would also slow down certain kinds of operations, like branching.
>
>
> I don't think so. Branching in our model is very simple, with or
> without "nodes". You just make a new directory entry pointing to the
> node-revision you're branching from. You don't even have to recurse.

Hm. You may be right about that one.

-- 
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/