[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New FS API, open_path, cloning and dag_node_t

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2001-02-13 22:40:56 CET

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


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

Received on Sat Oct 21 14:36:22 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.