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

Locking: taking a stand.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-11-03 02:14:24 CET

Okay, I'm going to stop waffling and take a position.

There are two things that need to be accomplished:

   1. implement a locks table (or tree) of some kind.

   2. implement logic which knows exactly when to consult the locks

I've gotten to the point where I flat-out dislike the idea of
implementing locks in libsvn_repos. Yes, the idea is nice in that it
means that we only need to implement #1 exactly once, that it could
be shared by all backends (BDB, FSFS, and maybe someday SQL). But I
think this niceness is eclipsed by two big problems:

    - The shared implementation of #1 would have to be something
      non-databaseish, which is a real limitation. Chances are that
      BDB or SQL may be able to implement the lock table a lot more
      efficiently using native database methods. Is it really worth
      closing that door?

    - This strategy places the entire burden of #2 on *every* process
      that accesses the repository: mod_dav_svn, svnserve, viewcvs,
      trac, svk, wikis, etc... as well as every future program.
      Granted, at a minimum, these programs could consult the locks
      table only at final commit time; but most users would expect
      things to fail the moment a locked file is changed.

I feel that's it's an unfriendly and unfair burden to pawn off all
that responsibility to the users of libsvn_fs. It's one thing to say,
"want hooks to fire? then call these two repos wrappers when you
start and end a commit." It's a totally different ball-park to say,
"want locks to be enforced? Then here's a long set of rules; make
sure you check for locks before calling any of the following fs
functions..." The logic gets duplicated over and over, and the
potential for error increases. It ceases to be a good API.

I think I agree with cmpilato here: locks are a true feature of
libsvn_fs, and should be enforced by libsvn_fs, just like ACLs would
be. Honoring a lock shouldn't be an optional convenience offered by a
user of libsvn_fs, nor should ignoring a lock ever be accidental. If
somebody locks a file with a 1.2 client, it shouldn't be possible for
an older (pre-1.2) user of libsvn_fs to accidentally ignore the lock.

At this point, I'm already well on the way to documenting the exact
APIs for #1 and the logic rules for #2; all we need to do is make
libsvn_fs_base and libsvn_fs_fs implement these things. Yes, it's a
bit more work, but I think it's the better design in the long run.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 3 02:14:51 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.