Jim Blandy <jimb@zwingli.cygnus.com> writes:
> > 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.
>
> For what it's worth, that interface (creating a dag_node_t given a
> node ID) was only needed by the clone tracking stuff. So that
> function could go away.
I already responded to this saying "sure, that's cool".
But before we make such a change, I'd want to understand what methods
we would use to retrieve dag_node_t's from the database. The pattern
would be: first grab a revision or txn root, then to get stuff beneath
that using svn_fs__dag_open(), right?
And of course, functions that currently return svn_fs_id_t (by
reference) would return dag_node_t instead... functions such as:
svn_fs__get_node_revision()
svn_fs__get_txn()
svn_fs__create_successor()
Hmmm. Okay. If it's the case that everywhere we currently retrieve
an id, the very next thing we do is use that id as a key to get the
node's contents, then the change makes a lot of sense -- why impose an
extra step on callers? But if that's not the case, then maybe the
status quo is fine.
-K
Received on Sat Oct 21 14:36:22 2006