On Nov 2, 2004, at 11:17 AM, Greg Hudson wrote:
> 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
>> 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.
A quick check of SubWiki shows that it does indeed use
> 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).
We should probably start another thread to discuss this, but I'd much
prefer to see the lock table implemented as a DAG.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Nov 2 18:43:48 2004