Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> Now, here's the issue: While hammering on tree.c to get it in line with
> the new FS API, I decded (and it seems that Jim tentatively agrees) that
> we need a function that will call svn_fs__dag_open repeatedly to
> traverse a path. It's called open_path in tree.c as of Jim's latest commits.
>
> Now, often we'll call this function because we only want to read a node,
> but sometimes we'll want to clone the node (for modifications) or its
> parent (for delete). The cloning has to bubble up the path until it
> reaches the root or a mutable node.
>
> Now, what I'm proposing is that a) dag_node_t keeps track of its parent
> and its name in the parent, and b) that open_path should construct a
> list of DAG nodes. This node list could then be used directly to clone
> the whole path.
>
> This wouldn't increase processing time or memory footprint. One
> potential problem is that we'd have to be careful not to hold on to the
> node list past the lifetime of a trail, but I think we have to watch
> that anyway.
>
> Thoughts?
Well...
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).
The information you're trying to preserve isn't information the dag
filesystem knows or cares about -- parent information is important
only to the "virtual filesystem", uh, perhaps better called the
"versioning filesystem". (Whichever it is, I'll call it the vfs from
now on).
A dag_node_t is currently something we can retrieve by key (see
svn_fs_id_t). The value associated with that key knows nothing about
parent information. So if dag_node_t had a parent fields, then when
we retrieve a dag_node_t it would have to be incomplete.
Remember svn_fs_node_t? Tracking this kind of information was one of
the main reasons we had it. Svn_fs_node_t was a superset of
dag_node_t; it held the dag node and also the metadata needed to
differentiate two nodes in the vfs even if they shared the same
underlying dag node.
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?
-Karl
> (Just to illustrate the proposed change:
>
> Index: dag.c
> ===================================================================
> RCS file: /cvs/subversion/subversion/libsvn_fs/dag.c,v
> retrieving revision 1.14
> diff -u -r1.14 dag.c
> --- dag.c 2001/02/13 16:38:35 1.14
> +++ dag.c 2001/02/13 23:10:35
> @@ -34,6 +34,12 @@
> into an svn_fs_id_t). */
> svn_fs_id_t *id;
>
> + /* The node's parent node, NULL if this is the root. */
> + dag_node_t* parent;
> +
> + /* The node's name in PARENT. */
> + const char* name;
> +
> /* The contents of the node (i.e., the DB value, parsed into a
> skel). */
> skel_t *contents;
> @@ -204,6 +210,10 @@
> const char *name,
> trail_t *trail)
> {
> + /* Do the opening bits, then ... */
> + child->parent = parent;
> + child->name = name;
> +
> abort();
> /* NOTREACHED */
> return NULL;
>
>
>
> --
> 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/
Received on Sat Oct 21 14:36:22 2006