Greg Hudson wrote:
> * Branko thinks the locking implementation can be combined with the
> ACL implementation, and ACLs almost certainly need to live in the
> FS layer. (But Branko has not graced us with a design document
> for ACLs.)
>
>
Yes... I procrastinated too long, again...
> * Branko has also argued that a database implementation of the
> repository would want to store the locks in the database. (But he
> also thinks you'd want to store the hooks and everything else in
> there too, so that argument is predicated on a disagreement with
> the current repository design.)
>
>
Huh? Did I say that? I may have theorised that a backend using a
/relational/ database would want to put everythong in the database,
sure. That doesn't mean I don't agree with the current separation used
by the BDB and FSFS back-ends.
>And here are the argments for putting it in the repos layer:
>
> * Since locks are not versioned objects and don't apply to
> historical resources (they only apply to the current version of a
> specified pathname), it might be appropriate to consider them not
> to be a feature of the versioned filesystem but as a separate
> feature of the version control system. In which case it's not
> appropriate to implement it in the FS layer.
>
> * The data currently managed by libsvn_fs is versioned, so adding
> locks would be breaking precedent.
>
>
Revprops aren't versioned.
(A mistake IMHO, but that's another story entirely and I certainly
wouldn't want to try to fix it before 2.0)
> * The data currently managed by libsvn_fs is dumped and loaded, so
> adding locks would be breaking precedent.
>
The changes table isn't...
> Unless you think locks
> should be part of a dump and load, which is entirely possible. I
> don't think we've discussed that yet.
>
>
*shudder
*
> * It's less work to put the locks table in the repository layer than
> it is to implement it in two FS modules.
>
>
That's true. But it's also an argument against having two FS modules in
the first place. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 29 08:48:43 2004