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

Re: How much libsvn_repos wrap around the libsvn_fs

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-12-20 15:17:22 CET

"Nitin Shukla" <nitinshukla@infotech.stph.net> writes:

> I am interested in knowing what are the other events which will be
> interfaced by the repository access library, as these would empower hooks to
> have fine control over the access to the repository?

Someday we hope to have not just 'write' hooks (start-commit,
pre-commit, post-commit), but 'read' hooks as well: these would
somehow create pipes to long-running hook processes (we call them
"sentinels") that would allow or disallow clients to read specific
paths in the repository.

Nitin, maybe we should cut to the chase here. :-) I know that you've
been assigned to implement some kind of fine-grained ACL system on top
of Subversion. There are three ways you can do this, I believe, in
increasing order of complexity:

1. Write an custom apache module to do authentication of every
    incoming HTTP request to the Subversion repository. Your apache
    module could speak to a database containing ACLs. It's easy for
    your module to distinguish between read requests (GET, PROPFIND,
    OPTIONS, REPORT) and write requests (PUT, PROPPATCH, COPY, etc.)

2. Write some complex write-hook programs, using the existing hook
    feature in libsvn_repos. Presumably these write-hook programs
    would also speak to a database containing ACL information. That's
    the easy part: the harder part is the fact that we don't yet have
    any read-hooks. We'd need to design that feature and add it to

3. Design an ACL system that is inherent to libsvn_fs. This is the
    difficult theoretical problem that nobody has been able to tackle
    yet. It's very hard.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 20 15:20:05 2002

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