On Fri, Jan 03, 2003 at 10:50:20PM -0500, Greg Hudson wrote:
> On Fri, 2003-01-03 at 22:36, Justin Erenkrantz wrote:
> > DAV specifically allows locks to disappear at any time for any reason
>
> Really? Here's an idea:
Yup, really :-)
DAV clients "should" record two items: the locktoken and the etag of the
item that they fetched. Should they lose the locktoken for any reason, they
can reaquire the lock and then check the etag of whatever they locked. If
the etag hasn't changed, then the client can continue on as if nothing
happened. If the etag *did* change, then the client may need to merge local
changes against whatever happened on the server.
> 1. Encode a node-revision or crev in the lock token.
> 2. Store no state about the lock on the server.
> 3. Logically speaking, if the resource is modified while the lock is
> held, then the lock has been "discarded." But since we're not
> keeping state about locks, that's an abstract idea.
> 4. When a lock token is used, return an error if the crev or
> node-revision in the lock token is no longer current for the
> resource. (Uh, hrm, unless the lock token was used to make that
> update. I don't suppose we get to return a new lock token or
> anything so that we can update the expected crev. This could be a
> catching point.)
Nope. Can't return a new token. However, you could have a commit toss all
related tokens. But then the UNLOCK would fail and some (poorly written)
clients might not appreciate that :-) (dunno if that actually applies)
Walking a commit to toss tokens introduces races and could pose a number of
other problems. Ideally, it would be good to go with the spirit of what you
suggest: at locktoken usage time, verify whether it still applies, and
"expire" the thing if it doesn't. The basic problem is, "oh. it changed. did
I do that, or did somebody else?"
One comment: Microsoft Office doesn't like the locks to expire on it. It is
written very poorly in this regard :-( It won't reaquire the lock, and if I
recall correctly, you can't even do a "save as" to save the document to the
local disk (presumbably cuz it tries to unlock the doc on the server, but
fails since the lock no longer exists). Ideal operation says to avoid
expiring locks whenever possible.
[ well, locks *do* have a notion of expiry time; Office will refresh the
lock "near" the expiry time; of course, it also does it "too near" and
network latencies kill off the lock... (mod_dav gives clients a two minute
margin to refresh their lock just cuz of Office) ]
Isn't it just fun when a standard has so much variety? :-)
> In this implementation, a lock is purely an onus on the locker and not
> on the other clients--a degenerate but compliant implementation of
> breakable locks. And it should be easy to implement because there is no
> new state to be stored.
Unfortunately, I think that *some* state will be required to answer the
question of who modified the doc while the lock was held. Or, alternatively,
to "repoint" the locks when a change is made.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 4 12:31:37 2003