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

Re: Networking layer (Or: Greg Stein, we are at your service...)

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2001-03-20 23:20:45 CET

Greg Stein <gstein@lyra.org> writes:
> > Greg Stein, is there any functionality you're still waiting for? Ask
> > and it shall be yours...
> Not that I know of, beyond an FS interface to "open by ID".

What interface would you like? You need read access to a node's
contents, and read access to its properties (including listing them,
and getting their values), right? The reason I ask is that there's no
actual `node' data structure exported by svn_fs.h currently. We
*talk* about nodes, but we only offer roots and paths :-).

Jim proposed the following wicked solution on the phone with me just

All those public fs functions that take a root and a path? Well, when
they see a path of the form


or whatever (you know the regexp I'm thinking of), they'll just behave
as if they'd found a path to that node, in ROOT->fs. Whether ROOT is
a revision root or a transaction root will be ignored, as we only need
the fs.

This totally punts on the ACL question, which is fine for now. We
need to get the networking up.

This probably results in the smallest code perturbance, and certainly
in the smallest interface perturbance. The alternative is to
reimplement a lot of the svn_fs.h root/path reading functionality, but
based on IDs instead of roots and paths. Bleargh. Major interface
redundancy. A draft of that is included below as a postscript, but I
think Jim's solution is better.


P.S. The aforementioned alternative:

   /* An object representing a node in a Subversion filesystem. */
   typedef struct svn_fs_node_t svn_fs_node_t;
   /* Set *NODE to the node identified by ID in FS, allocating the new
    * node in a subpool of POOL.
   svn_error_t *svn_fs_get_node (svn_fs_node_t **node,
                                 svn_fs_id_t *id,
                                 svn_fs_t *fs,
                                 apr_pool_t *pool);
   /* Return non-zero iff NODE is a dir/file/symlink/armadillo. */
   int svn_fs_node_is_dir (svn_fs_node_t *node);
   int svn_fs_node_is_file (svn_fs_node_t *node);
   int svn_fs_node_is_symlink (svn_fs_node_t *node);
   int svn_fs_node_is_armadillo (svn_fs_node_t *node);
   /* Set *PROPS_P to a list of svn_string_t *'s, each of which is
    * the name of some property on NODE. All allocation is done in the
    * same pool NODE is allocated in.
    * [Or, use char * instead of svn_string_t *? Return a hash with
    * the values too, not just the names?]
   svn_error_t *svn_fs_node_list_properties (apr_array_header_t **props_p,
                                             svn_fs_node_t *node);
   /* Set *VALUE to the value of property NAME in NODE. All
    * allocation is done in the same pool NODE is allocated in.
    * [Or... see comment above svn_fs_node_list_properties.]
   svn_error_t *svn_fs_node_get_property (svn_string_t **value,
                                          svn_string_t *name,
                                          svn_fs_node_t *node);
   /* Set *RSTREAM to a read stream for obtaining the contents of
    * NODE. NODE must be a file node. All allocation is done in the
    * same pool NODE is allocated in.
   svn_error_t *svn_fs_node_get_contents (svn_stream_t *rstream,
                                          svn_fs_node_t *node);
   /* Set *ENTRIES to a hash table representing NODE's entries. NODE
    * must be a directory node. The table maps char * entry names
    * onto svn_fs_dirent_t *'s. All allocation is done in the same
    * pool NODE is allocated in.
   svn_error_t *svn_fs_node_get_entries (apr_hash_t **entries,
                                         svn_fs_node_t *node);
   /* Destroy the pool NODE is allocated in. */
   svn_error_t *svn_fs_node_free (svn_fs_node_t *node);

Or, substitute "_id_" for "_node_" and don't even have a node object.
But then everything would have to take pool and filesystem arguments.
Received on Sat Oct 21 14:36:26 2006

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