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

Locking server implementation: libsvn_repos or libsvn_fs

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-10-28 23:50:25 CEST

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.