Ben's document says:
* where does the lock-table live?
It can't be in libsvn_repos; not unless we force every program in
the universe to stop using libsvn_fs write-calls, and use a slew of
new libsvn_repos 'wrapper' functions instead. Not likely.
As I just convinced Ben over IRC, that argument doesn't hold water.
We could manage the lock table in the repos layer and add an API to
"check transaction against lock table" which is invoked by mod_dav_svn
and the libsvn_repos commit editor prior to commit.
Here are the arguments I know of for putting the lock table in the FS
back end:
* If you think locking is a feature of a versioned filesystem, it's
burdensome for callers changing the filesystem to have to
explicitly check against an external (to the FS) lock table.
* The data currently managed by libsvn_repos is read-only (unless
you think of the recovery lock file as read-write, and that lock
file belonged in the FS layer anyway since it's working around a
BDB limitation), so adding locks would be breaking precedent.
* 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.)
* 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.)
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.
* The data currently managed by libsvn_fs is dumped and loaded, so
adding locks would be breaking precedent. 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.
* It's less work to put the locks table in the repository layer than
it is to implement it in two FS modules.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 28 23:51:18 2004