On Nov 2, 2004, at 7:14 PM, Ben Collins-Sussman wrote:
> 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.
+1
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 3 07:34:44 2004