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
table.
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