[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: Jim Blandy <jimb_at_zwingli.cygnus.com>
Date: 2001-02-15 17:22:16 CET

Karl Fogel <kfogel@galois.collab.net> writes:
> Jim Blandy <jimb@zwingli.cygnus.com> writes:
> > 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()

No. Those functions will continue to use svn_fs_id_t. They are
*used* by the dag filesystem. I'm talking about removing this
function *exported* by the dag filesystem:

    /* Open the mutable node in the transaction named TXN whose ID is ID
       in FS, as part of TRAIL; set *NODE_P to the new node. Allocate the
       node in TRAIL->pool. */
    svn_error_t *svn_fs__dag_txn_node (dag_node_t **node_p,
                                       svn_fs_t *fs,
                                       const char *txn,
                                       const svn_fs_id_t *id,
                                       trail_t *trail);
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.