Here's a heads-up for folks following what's going on in the locking
branch.
After a bunch of discussion yesterday, cmpilato and kfogel feel that
it was a mistake to put on-the-fly lock checking directly into public
fs routines. (BDB is doing this now, FSFS isn't quite there yet.)
It turns out that we have a precedent for this, one which I
misunderstood: it's the way in which the filesystem does
out-of-dateness checks. Apparently only svn_fs_commit_txn() actually
does out-of-dateness checks. All of the other on-the-fly
out-of-dateness checks are being done by *servers* -- specifically, in
the commit editors implemented by the servers.
I guess the rationale here is that a libsvn_fs transaction tree is
supposed to represent a "generic scratch space". libsvn_fs isn't in
the business of telling users what they may or may not assemble in
their scratch space; if users want to drop out-of-date files in there
and edit them, that's their own business. Who knows if the user even
plans to commit the transaction? (Remember that in svn 1.0,
transaction trees were created just to do updates!) libsvn_fs only
enforces out-of-dateness if the user tries to merge the tree into
HEAD.
In that same vein, libsvn_fs shouldn't be in the business of
preventing users from editing locked files in their tree. libsvn_fs
only does enforcement of *both* out-of-dateness and locks when the
user tries to commit.
So I'm going to rip the on-the-fly lock checking out of BDB's public
fs funcs, and fitz going to avoid coding that feature in FSFS.
Meanwhile, I'm going to create some libsvn_repos wrappers around the 8
or so fs-write routines. These wrappers will do on-the-fly lock
checking, and will be optionally available for use by both server
processes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 2 15:28:49 2004