You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@galois.collab.net> on 2001/03/16 19:09:52 UTC
Networking layer (Or: Greg Stein, we are at your service...)
Repository and client library functionality are pretty substantial
now. There should be nothing preventing the networking layer from
doing basic checkouts and commits (with updates coming very soon).
Greg Stein, is there any functionality you're still waiting for? Ask
and it shall be yours...
-K
Re: open by ID interface (was: Re: Networking layer ...)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Mar 22, 2001 at 02:22:46PM -0500, Jim Blandy wrote:
> Greg Stein <gs...@lyra.org> writes:
> > > You need read access to a node's
> > > contents, and read access to its properties (including listing them,
> > > and getting their values), right?
> >
> > Right. A hash table of the props is quite fine. I can go from there.
> >
> > I believe that I only need file contents and file/dir props; not a dir's
> > entries.
>
> I think if we're going to provide a piece of functionality, we should
> try to provide all the features that make sense given the semantics of
Never said otherwise. Just stating my minimum requirements. I'd expect the
rest, but don't really need it right now.
>...
> It occurred to me that we don't need to pull any nasty syntactic
> tricks like this that take over certain filenames for magical
> meanings.
>
> Add the following function to svn_fs.h:
That works quite well.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: open by ID interface (was: Re: Networking layer ...)
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Greg Stein <gs...@lyra.org> writes:
> > You need read access to a node's
> > contents, and read access to its properties (including listing them,
> > and getting their values), right?
>
> Right. A hash table of the props is quite fine. I can go from there.
>
> I believe that I only need file contents and file/dir props; not a dir's
> entries.
I think if we're going to provide a piece of functionality, we should
try to provide all the features that make sense given the semantics of
the underlying filesystem. When you implement functionality piecemeal
based on what you need today, what I've often seen is the later growth
of a tangle of workarounds and "minor" extensions. If one has the
energy, I think it's better to keep all the "cells in the matrix
filled in," if you see what I mean. One should at least spec them
out, even if you don't actually implement them.
Anyway, all the newer proposals meet that requirement, so it's fine.
> > All those public fs functions that take a root and a path? Well, when
> > they see a path of the form
> >
> > "//3.4.5.17"
> >
> > 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.
>
> I'd recommend something like ":ID" since the code/comments specifically
> allow for multiple slashes.
It occurred to me that we don't need to pull any nasty syntactic
tricks like this that take over certain filenames for magical
meanings.
Add the following function to svn_fs.h:
/* Set *ROOT_P to a root object that can be used to access nodes by
node revision ID in FS. Whenever you pass *ROOT_P to a filesystem
access function, any filename "relative" to *ROOT_P must actually
be the printed form of a node revision ID: a sequence of decimal
numbers without leading zeros, separated by '.' characters,
containing an even number of numbers. Allocate ROOT_P in POOL. */
svn_error_t *svn_fs_id_root (svn_fs_root_t *root_p,
svn_fs_t *fs,
apr_pool_t *pool);
Then we can simply used the printed form of node revision ID's as
paths, with no ambiguity. In implementation, we just add a new value
to root_kind_t, and adapt open_path to behave accordingly.
open by ID interface (was: Re: Networking layer ...)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Mar 20, 2001 at 04:20:45PM -0600, Karl Fogel wrote:
> Greg Stein <gs...@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?
Hadn't thought too much on it yet :-)
> You need read access to a node's
> contents, and read access to its properties (including listing them,
> and getting their values), right?
Right. A hash table of the props is quite fine. I can go from there.
I believe that I only need file contents and file/dir props; not a dir's
entries.
>...
> All those public fs functions that take a root and a path? Well, when
> they see a path of the form
>
> "//3.4.5.17"
>
> 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.
I'd recommend something like ":ID" since the code/comments specifically
allow for multiple slashes.
> This totally punts on the ACL question, which is fine for now. We
> need to get the networking up.
I've got to dump some of the results of the thread into a doc, but I'm
currently leaning towards "punt ACLs to post-1.0". CVS doesn't have them, we
have (at least) Apache ACLs, so why do we need more for 1.0?
But whether or not, there are a number of things to ponder on, which are
unique to our situation, so I'll be dumping that into a notes doc.
> 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.
I'm fine with that solution, too, with the ":ID" suggestion.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Networking layer (Or: Greg Stein, we are at your service...)
Posted by Ben Collins-Sussman <su...@newton.ch.collab.net>.
Karl Fogel <kf...@galois.ch.collab.net> writes:
> 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);
The last func is critical. :)
Re: Networking layer (Or: Greg Stein, we are at your service...)
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@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
now:
All those public fs functions that take a root and a path? Well, when
they see a path of the form
"//3.4.5.17"
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.
-Karl
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.
Re: Networking layer (Or: Greg Stein, we are at your service...)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 16, 2001 at 01:09:52PM -0600, Karl Fogel wrote:
> Repository and client library functionality are pretty substantial
> now. There should be nothing preventing the networking layer from
> doing basic checkouts and commits (with updates coming very soon).
>
> 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".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/