Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> > The parent information should not be recorded in dag_node_t. A
> > dag_node_t represents a node in the dag filesystem, and may have
> > multiple parents (even in one revision tree).
>
> Yes, but during the lifetime of a trail -- that is, within one
> "tree.c"-level operation -- we're interested only in the path we used to
> reach the node.
Hah. Get your caller out of my interface. :-)
For you, one trail corresponds to one tree.c operation. But I, in my
splendiferous, magnificent, glittering editorusness, may do any old
operation I please on a dag_node_t, so long as it matches the dag
semantics.
Awa-ha-ha-ha-haaaaah.
> > So maybe the real question is: should we still have svn_fs_node_t or
> > something like it, at least to preserve the
> > path-by-which-we-got-to-this-dag-node and any other information
> > layered on top of dag nodes?
>
> We do. Otherwise we can't clone a whole path. Remember that we /do/ need
> to clone a (sub) path in every FS operation that modifies a node. We can
> only do that if we have a list of dag nodes that corresponds to the path.
>
> Actually, we need a list of (node, name) pairs, where each "name" is a
> path component. That's because we have to modify the dir entry called
> "name" when we clone a node's child.
>
> open_node can create this list (it has all the bits at its fingertips).
> Maybe we should have something like this:
>
> struct named_node {
> const char *name;
> dag_node_t *node;
> };
>
> svn_error_t *open_path (apr_array_header_t **named_nodes,
> svn_fs_root_t *root,
> const char *path,
> trail_t *trail);
Sure. I think we're talking about a data structure at roughly the
same exposure level as skel_t and stuff like that, so go ahead and
whip together whatever you need.
-K
Received on Sat Oct 21 14:36:22 2006