On Tue, 2004-11-02 at 12:04, Brian W. Fitzpatrick wrote:
> > Then they will also circumvent hooks, won't they?
>
> Yes. And that's really the big thing that Bugs Me. Hooks will be in
> the repos layer, and if we implement locking policy via hooks, how
> could we possible call the hooks from the fs layer? And the thought of
> wrapping every fs call in a repos call makes me kind of ill.
Even if we implement locks in the FS, the only calls we need to wrap in
libsvn_repos for the sake of hooks are lock and unlock, since those are
the only calls which will trigger hook scripts.
If we implement locks in the repos layer, I'll note that mod_dav_svn
(and I hope subwiki) go through svn_repos_fs_commit_txn in order to
trigger hooks. We can put a lock check there, so things like subwiki
won't be circumventing locks. (If an RA layer wants to check locks
before the final stage of a commit for the sake of early rejection, it
can do so manually or by using the libsvn_repos commit editor, but that
argument doesn't have to do with circumvention.)
CMike wrote:
> To be honest, I think I'm settling into the locks-in-fs camp, if only
> because I see them as being consumed (implementation-wise, if not
> UI-wise as well) by ACLs eventually, which I think no one debates
> should live in the FS.
I don't have a strong opinion either way on repos vs. fs, but if we're
going to make the decision for that reason, I really really want to see
a design document for ACLs. Because I am not at all convinced that a
good implementation of a lock table (which maps pathnames to lock
tokens, and has no history) shares much in common with a good
implementation of an acl system (which maps node-revs to access control
lists, and may want to have history).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 2 18:17:32 2004