RE: Adding a no-op LOCK to mod_dav_svn

> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Saturday, January 04, 2003 4:50 AM
> To: Justin Erenkrantz
> Cc: dev@subversion.tigris.org
> Subject: Re: Adding a no-op LOCK to mod_dav_svn
>
>
> 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:
>
> 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.)
>
> 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.

This sounds like you're suggesting to allow multiple clients to WebDAV-LOCK
the same resource at the same time, obtaining the same lock token. This
would be compliant if the clients would indeed ask for shared locks (but
they don't). Returning the same lock token (essentially identifiers to the
same lock) upon multiple LOCK requests would be a protocol violation (see
RFC2518, section 6.3).

As far as I understand, a lock table (whether persisted or not) would have
to record:

a) an identifier of the resource that's stable even when the name changes
b) the etag (or something equivalent)
c) a counter of locks issued for this resource

c) can be a single counter that is incremented for any lock that is issued.
a) and b) should be known anyway.

If the lock table is not persisted (which is legal), one will need to make
sure that counter c) does not re-use existing values.

Proposal:

1) Upon server start/restart, obtain some fresh UUID.

2) Keep a counter of locks that were issued since the restart

3) Build lock tokens of the form (see RFC2518, section 6.4):

        "opaquelocktoken:" + uuid + "-" + "-" + counter "-" + nodeid + "-" + etag

4) Keep a list of all resources that were locked, and the lock token that
was issued (and ideally some owner information -- some clients will break if
the owner information they submit with the lock request isn't persisted!)

5) Do not support deep locks and/or shared locks.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org