At 10:09 PM 7/23/2004, you wrote:
>Read-hooks are hard to do, which is why we haven't implemented them
>yet. There are *many* read functions in the repository filesystem API
>(svn_fs.h). To implement read hooks, we'd have to "wrap" every one of
>these functions with libsvn_repos functions, and then have every program
>in the world use svn_repos.h instead of svn_fs.h for reading data.
>Messy.
I think what you are saying is that the filesystems are not encapsulated
behind the repository formalism, i.e. Subversion's design treats the
underlying database as a sort of "neighborhood bicycle" subject to
the whimsy of whatever higher-level module wants to go rooting through
its data structures. This makes a lot of sense in the context of the
original mentality, where the high-level interface to Subversion
is WebDAV, and WebDAV's feature set can thus be leveraged for
authentication, the user list, etc. In this mindset, svnserve exists
only as a consolation or marketing tool for amateurs who ask things
like "Why should I have to administer a web server in order to do
version control?" :-)
>We've even had talks about writing persistent daemons to speed up the
>fictional 'read' checks, lest things get too slow. The conversation
>gets messy. If you really want to talk about the design
Exactly; in order to solve these problems correctly, the user list
and authentication model will have to be changed so Subversion can
manage them independently of WebDAV. In fact, you alluded to something
like this in the svn-design document:
>>"For example, someday a hypothetical svn-acl property might hold
>>an access control list which the Subversion server uses to regulate
>>access to repository files."
My focus here is much more immediate; although I may have time to write
some C code, I want to avoid complicated design discussions. So here's
my proposal: Instead of worrying about hook scripts, why don't we just
expand svnserve's authentication model? In other words, we can implement
for svnserve a small subset of what WebDAV is doing. This should be an
inexpensive way to extend the old model until a proper ACL mechanism
is designed. I mean shit, svnserve could probably do this using
properties. So... how much work would this be? :-)
Cheers,
-Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 28 19:44:25 2004