RE: Adding a no-op LOCK to mod_dav_svn

> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Sunday, January 05, 2003 3:45 AM
> To: Julian Reschke
> Cc: dev@subversion.tigris.org
> Subject: Re: Adding a no-op LOCK to mod_dav_svn
>
> ...
>
> > 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.

You need to avoid to have the same lock token for the same URI as well.
Consider

PUT a
LOCK a
MOVE a -> b
PUT a
LOCK a

The two lock tokens issued MUST be different. Of course if you have c)
implemented as global counter, this is guaranteed anyway.

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

Yes. It avoids unnecessary UUID generation, which can be expensive.

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

OK, so some of the components may need escaping, depending on their syntax.

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

It may make sense to check the current implementation with the results of
the latest LOCK-related brainstorming on the WebDAV mailing list (note that
this is a simplified model that's compatible with RFC2518 and the new BIND
method, but doesn't mention the now-obsolete LOCK-NULL resources anymore):

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0079.html>

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