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

on-the-fly lock checking

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-12-02 15:27:25 CET

Here's a heads-up for folks following what's going on in the locking

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

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

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

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.