Greg Stein <gstein@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.
Received on Sat Oct 21 14:36:26 2006