Re: Adding a no-op LOCK to mod_dav_svn

On Sat, Jan 04, 2003 at 01:17:23PM +0100, Julian Reschke wrote:
>...
> > 2. Store no state about the lock on the server.
>...
> 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).

Heh... quite right; I had really missed that part :-)

> 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.

I don't understand (a). Locks don't move with the resource, so the name
would never change.

Note that (c) could also just be a server-wide counter; it doesn't
necessarily have to correspond to a single resource.

> 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.

Yup.

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

Hunh. I missed this optimization. It can only work if you use the
"Extension" in the definition of the opaquelocktoken scheme. Neat.

> 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

Anything following the uuid must be an RFC2616 "path".

> 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.

Yes, this would simplify things.

Justin Erenkrantz has taken the locking code out of mod_dav_fs, simplified
it, and checked it into Apache 2.1 as mod_dav_lock. It is basically a
generic locking provider, and supports "everything" about locks (exclusive,
shared, deep, record the owner, etc).

It will be interesting to see how well it works with mod_dav_svn. Also,
whether it can detect a "loss of lock" if the repository changes through
something besides DAV (e.g. local access).

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