On Tue, Mar 20, 2001 at 04:20:45PM -0600, Karl Fogel wrote:
> Greg Stein <firstname.lastname@example.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
> 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.
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.
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:26 2006