[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: Julian Reschke <julian.reschke_at_gmx.de>
Date: 2005-03-19 23:13:44 CET

Ben Collins-Sussman wrote:
> On Mar 19, 2005, at 8:44 AM, Julian Reschke wrote:
>>> If RFC2518bis expects a LOCK on a NULL resource to be handled as a
>>> 0-byte PUT, then I guess a 2518bis-conformant client *should* expect
>>> to see the object listed in the parent. It's no longer a NULL resource.
>> Right.
> I'm a bit frustrated, because I feel like we're just guessing what DAV
> clients are "likely" to do
> Might the client do a LOCK; MKCOL? Then we shouldn't be doing the
> 0-byte PUT thing. We should allow libsvn_fs to create locks on
> nonexistent paths, i.e. truly support lock-nulls.

If a client tries that, it will fail to work with many existing servers.
Are you aware of any clients showing that behaviour?

> Might the client do a LOCK; PROPFIND-depth-1? If so, then we should be
> actively trying to support the showing lock-nulls within parent
> directories. This is easy to do if we do the 0-byte PUT thing, but
> somewhat inefficient if libsvn_fs really supports locks on nonexistent
> things.

I don't know if any clients do that, but they certainly can expect that
from both RFC2518 and RFC2518bis.

> In reality, it seems like clients only ever do LOCK; PUT. How much
> guessing do we need to do? How far should we go?

I'd recommend to stick to what RFC2518bis requires.


<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
Received on Sat Mar 19 23:15:34 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.