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

Re: Locking non-existent paths. Time to discuss.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-20 02:09:59 CET

On Mar 19, 2005, at 4:13 PM, Julian Reschke wrote:
>
> I'd recommend to stick to what RFC2518bis requires.
>

And here's the magic section from 2518bis that says absolutely
everything. Nicely written (from section 7.4):

    A lock request to an unmapped URL SHOULD result in the creation of an
    locked resource with empty content. A subsequent PUT request with
    the correct lock token SHOULD normally succeed, and this new request
    provides the content, content-type, content-language and other
    information as appropriate.

    In this situation, a WebDAV server that was implemented from RFC2518
    MAY create "lock-null" resources which are special and unusual
    resources. Historically, a lock-null resource:

    o Responds with a 404 or 405 to any DAV method except for PUT,
       MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
    o Appears as a member of its parent collection.
    o Disappears (URI becomes unmapped) if its lock goes away before it
       is converted to a regular resource. (This must also happen if it
       is renamed or moved, or if any parent collection is renamed or
       moved, because locks are tied to URLs).
    o May be turned into a regular resource when a PUT request to the
       URL is successful. Ceases to be a lock-null resource.
    o May be turned into a collection when a MKCOL request to the URL is
       successful. Ceases to be a lock-null resource.
    o Has defined values for lockdiscovery and supportedlock properties.

    However, interoperability and compliance problems have been found
    with lock-null resources. Therefore, they are deprecated. WebDAV
    servers SHOULD create regular locked empty resources, which are and
    behave in every way as normal resources. A locked empty resource:

    o Can be read, deleted, moved, copied, and in all ways behave as a
       regular resource, not a lock-null resource.
    o Appears as a member of its parent collection.
    o SHOULD NOT disappear when its lock goes away (clients must
       therefore be responsible for cleaning up their own mess, as with
       any other operation)
    o SHOULD default to having no content type.
    o MAY NOT have values for properties like getcontentlanguage which
       haven't been specified yet by the client.

Gee, this seems pretty clean and simple. As ghudson said, we're
already disallowing lock-null features in the client. It would be
'KISS' to disable lock-nulls in libsvn_fs altogether, and just teach
mod_dav_svn (and *only* mod_dav_svn) to do the 0-byte PUT thing when a
LOCK comes in from a non-svn client. Once we have that, we end up

    * completely compliant with 2518bis
    * not having to worry about inefficient listing algorithms
    * not having to worry about 'cleaning up' the 0-byte files
    * isolating the weirdness to mod_dav_svn alone
    * still interoperating with MS Office

This seems like the best of all worlds to me.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 20 02:11:24 2005

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.