You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2005/03/16 19:09:09 UTC
Locking non-existent paths. Time to discuss.
Even though it's very late in the game, there are some critical
decisions we need to make about locking features. They tend to
cascade out from each other.
* Fact: libsvn_fs allows already locks on non-existent paths. This
feature exists to be interoperable with generic DAV clients. In DAV
parlance, such things are called 'lock-null' resources. That is:
they're 'null' resources (they don't exist), but are still locked.
* Fact: DAV clients expect to be able to PROPFIND on lock-null
resources (to see the lock), and they also expect lock-null objects
to be listed as children of directories. (Done by doing depth-1
PROPFIND on a directory.) cmpilato and I are currently working on
adding these behaviors to mod_dav_svn.
Question 1: Given that lock-null resources might exist, should svn
clients be able to see them? And to what extent?
* 'svnadmin lslocks' already shows them.
* 'svn status -u' shows remote locks on real files. Should it
also show remote lock-null objects? This may prove very
difficult to do; lundblad is working on it.
* should 'svn info URL' show lock information if URL is a
lock-null resource? It would be easy to do.
* should 'svn ls' (i.e. svn_ra_get_dir()) show lock-null resources?
Question 2: Should the svn client (and API) be able to lock
nonexistent paths?
* 'svn lock URL' is able to do this right now, though we could
easily prevent it if we wanted to.
* philip has argued that it would be useful to 'svn lock' a
schedule-add file. While it may not prevent others from wasting
time on conflicting schedule-adds, it *does* have the effect of
reserving the whole path; that is, nobody can delete any parent
directory of the schedule-add file.
cmpilato and I are running up against these questions on our quest to
make mod_dav_svn list lock-null children in directory listings.
Should mod_dav_svn only be showing these things to generic DAV
clients? Or should svn clients see them too? And if so, that would
mean making all three RA layers show lock-null children... and at that
point, perhaps svn_fs_dir_entries() should be returning them, right?
So we need to get these larger questions sorted out first.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > * 'svn status -u' shows remote locks on real files. Should it
> > also show remote lock-null objects? This may prove very
> > difficult to do; lundblad is working on it.
> >
> The biggest problem here is that libsvn_wc/status.c is a little hard to
> understand (at least for me). I am doing this.
Er. Sorry about that. :-)
> > * should 'svn info URL' show lock information if URL is a
> > lock-null resource? It would be easy to do.
> >
> > * should 'svn ls' (i.e. svn_ra_get_dir()) show lock-null resources?
> >
> I think this is easy if the locked non-existent paths or direct children
> of some non-existent path. But you could also lock something not a direct
> child. Should we return phantom intermidate paths? (I'm talking about the
> --recursive case.)
I think you meant:
I think this is easy if the locked non-existent paths are direct
children of some existent path.
Making this a requirement is, in my opinion, the difference between
infeasible/insane and feasible/sane.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 16 Mar 2005, Ben Collins-Sussman wrote:
> Question 1: Given that lock-null resources might exist, should svn
> clients be able to see them? And to what extent?
>
> * 'svnadmin lslocks' already shows them.
>
> * 'svn status -u' shows remote locks on real files. Should it
> also show remote lock-null objects? This may prove very
> difficult to do; lundblad is working on it.
>
The biggest problem here is that libsvn_wc/status.c is a little hard to
understand (at least for me). I am doing this.
> * should 'svn info URL' show lock information if URL is a
> lock-null resource? It would be easy to do.
>
> * should 'svn ls' (i.e. svn_ra_get_dir()) show lock-null resources?
>
I think this is easy if the locked non-existent paths or direct children
of some non-existent path. But you could also lock something not a direct
child. Should we return phantom intermidate paths? (I'm talking about the
--recursive case.)
> Question 2: Should the svn client (and API) be able to lock
> nonexistent paths?
>
A problem with this is that the current implementation of svn up removing
defunct tokens uses the editor and entryrops. If someone locks a
schedule-add path, then that lock becomes defunct, we'd want to remove
that lock token from the WC. The editor can't open an non-existent path.
If think this feature would be nice, but it isn't a show-stopper.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Mar 16, 2005, at 4:37 PM, Ben Collins-Sussman wrote:
> 2. punt on locknull support in the client.
>
> - 'svn st -u' will not show lock-nulls.
> - 'svn info URL' will not show lock-nulls.
> - 'svn ls' will not list lock-null children.
> - 'svn lock/unlock URL' won't work on nonexistent paths.
> - 'svn lock wcpath' won't work on schedule-add paths.
>
> In theory, we've been worried about the scenario where a DAV
> client creates a lock-null resource, and then this starts to effect
> svn clients adversely. (e.g. an svn client tries to delete a
> directory, gets a locking error, but can't see the lock!) But our
> epiphany today was that in *practice*, lock-null resources don't last
> for more than a microsecond. The probability of affecting an svn
> client is miniscule. So we'd rather punt on these client features,
> and simply leave the door open to add them in svn 1.3 if there's
> demand.
I'm +1 all over that.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
Okay, after a day's worth of discussion and triage, cmpilato and I have
come up with a plan. Hope this doesn't rub anyone the wrong way.
We did some experiments. We completely disabled the ability to create
lock-null resources in libsvn_fs. Then we put up an authn-protected,
autoversioning repository and tried to stress-test as best we could.
We tested a bunch of DAV clients: MS Office 2000, OSX, Win2k
Webfolders, WinXP webfolders. These are the most popular DAV clients,
the ones most likely to take advantage of our new
locking/autoversioning features.
What we discovered was that MS Office *does* require the ability to
create lock-null resources. This is pretty big deal. We've been
striving to make autoversioning something really useful, and this is a
major DAV client. A lot of people will be annoyed by this.
So here's what we'd like to do for svn 1.2:
1. fully support lock-nulls in the server:
- libsvn_fs supports them already
- LOCK nonexistent-URL
- UNLOCK lock-null-URL
- PROPFIND lock-null-URL
- PROPFIND on parent shows lock-null children
We currently support everything in that list but the last
little bit. Mike Pilato is going to re-do the BDB locking tables to
emulate FSFS's system, then add a depth argument to svn_fs_get_locks().
(See my other email about this). It means that it will be a little
bit slower to do a depth-infinity fetch of locks, but it also means
that it will be *reasonable* to do a depth-1 fetch of locks, and thus
easily discover lock-null children. If we don't make this lock-table
schema change now, we'll be stuck with it till 2.0. So we want to get
it right the first time; we won't be able to casually add this last
feature in 1.3.
2. punt on locknull support in the client.
- 'svn st -u' will not show lock-nulls.
- 'svn info URL' will not show lock-nulls.
- 'svn ls' will not list lock-null children.
- 'svn lock/unlock URL' won't work on nonexistent paths.
- 'svn lock wcpath' won't work on schedule-add paths.
In theory, we've been worried about the scenario where a DAV
client creates a lock-null resource, and then this starts to effect svn
clients adversely. (e.g. an svn client tries to delete a directory,
gets a locking error, but can't see the lock!) But our epiphany today
was that in *practice*, lock-null resources don't last for more than a
microsecond. The probability of affecting an svn client is miniscule.
So we'd rather punt on these client features, and simply leave the door
open to add them in svn 1.3 if there's demand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> In reality, it seems like clients only ever do LOCK; PUT. How much
> guessing do we need to do? How far should we go?
... especially in light of the fact that we now already have the code
to do full support of (that portion of) the spec.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Greg Hudson <gh...@MIT.EDU>.
My opinion--not a terribly strong one, as my opinions go--is that we
should not support lock-null resources in libsvn_fs, even if that
requires an ugly hack in the autoversioning code. My reasoning comes
from the following principles:
* No unnecessary infrastructure: If we are not going to support
lock-null resources in the Subversion client, we do not want any
complexity from supporting it in the FS. (And if the W3C has decided
that lock-null resources are a bad idea after all, we should probably
follow their lead.) At first glance, it may appear like more complexity
*not* to support lock-null resources in the FS, but I don't think that's
true; if we have lock-null resources, then we need a way of discovering
them (merging locks into depth-1 directory listings, for instance) and
we need to check for them when we add a file or directory.
* Scalable performance: Supporting lock-null resources in the FS means
we need to be able to do depth-1 enumerations of the locks in a
directory. In the BDB back end, the most natural representation does
not allow that to be implemented in a very scalable fashion.
(Mitigating counterargument: in real life, you're not going to get huge
numbers of active locks in a repository unless you have people abusing
recursive locks as ACLs. So I'm not sure I care.)
* Segregation of complexity: auto-versioning is a non-core feature of
Subversion. So, to the greatest extent possible, any requirements it
introduces should be handled in the auto-versioning code, not in the
core. If this means we implement the deprecated lock-null feature by
guessing at what clients are going to do, so be it. (We were prepared
to simply not support lock-null resources under DAV until we found some
clients which cared about it; why do we now have cold feet about only
support it for file creation, when the W3C is telling us that's all it
gets used for?) I'll note that if we do want to support LOCK; MKCOL and
LOCK; COPY, we can probably do that by tampering with the
auto-versioning parts of MKCOL and COPY, which still restricts the
complexity to the auto-versioning code.
All that said, having half-assed support for lock-null resources in
libsvn_fs is perhaps the globally easiest thing to do, which is my
opinion isn't a strong one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 21, 2005, at 9:56 AM, Julian Reschke wrote:
>
> Ah. I forgot that SVN doesn't have checkout-in-place, right?
>
Yeah, that's the heart of the problem. We only support CHECKOUTs into
activities. It's a direct match with svn's versioning model.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 21, 2005, at 11:44 AM, Greg Hudson wrote:
> On Mon, 2005-03-21 at 11:07, C. Michael Pilato wrote:
>>> LOCK nonexistentURL
>>
>> ...commits a 0-length file, locked...
>>
>>> PUT 0-byte-file
>>
>> ...commits 0 more bytes to that 0-byte file... (leaving it locked)
>
> Can't we detect that this is a do-nothing transaction and elide the
> second commit? (I realize that this would require a special check
> inside the auto-versioning code.)
>
A wart on top of a wart? Is it worth it?
In my experience, the moment you turn on autoversioning, you start
getting lots of extraneous commits. Every DAV client behaves
differently, and most are not afraid of doing lots of useless writes.
They don't think there's any versioning going on, so why should they
care about the number of writes?
For example, when I drag a new file 'foo' to a DAV share is OSX Finder,
it does *5* writes: touch .foo, put data in .foo, delete .foo, touch
foo, put data in foo. That's 5 commits.
My feeling is that adding this special check isn't going to create any
noticable decrease in amount of 'noise' in the repository's history.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-03-21 at 11:07, C. Michael Pilato wrote:
> > LOCK nonexistentURL
>
> ...commits a 0-length file, locked...
>
> > PUT 0-byte-file
>
> ...commits 0 more bytes to that 0-byte file... (leaving it locked)
Can't we detect that this is a do-nothing transaction and elide the
second commit? (I realize that this would require a special check
inside the auto-versioning code.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Reschke <ju...@gmx.de> writes:
> > LOCK nonexistentURL
>
> ...would create an empty locked resource...
>
> > PUT 0-byte-file
>
> ...would check it out and update it with 0 byte content...
>
> > PUT real-file
>
> ...would update the content again...
>
> > UNLOCK URL
>
> ...would unlock it and check it back in (so a single version is created).
>
> But this requires the server to support checkout-in-place.
Right.
Instead, we get:
> LOCK nonexistentURL
...commits a 0-length file, locked...
> PUT 0-byte-file
...commits 0 more bytes to that 0-byte file... (leaving it locked)
> PUT real-file
...commits real content to the file, or 0 bytes again if the file
has no content... (leaving it locked)
> UNLOCK URL
...unlocks the file.
Three commits, just to do "Save As ...". Purty icky. But, if that's
the grossest thing we'll ever have to face in developing Subversion,
we're doing juuuuuuuust fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Julian Reschke <ju...@gmx.de>.
Ben Collins-Sussman wrote:
>
> On Mar 21, 2005, at 9:27 AM, Julian Reschke wrote:
>
>> Ben Collins-Sussman wrote:
>>
>>> On Mar 21, 2005, at 9:00 AM, Julian Reschke wrote:
>>>
>>>>
>>>> b) Even if it does, shouldn't the LOCK braces cause it to be a
>>>> single checkin? (see
>>>> <http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-
>>>> version>, DAV:checkout-unlocked-checkin).
>>>>
>>> mod_dav_svn defines 'DAV:auto-version' to always be
>>> 'DAV:checkout-checkin'.
>>
>>
>> Is there a good reason why it doesn't implement
>> "DAV:checkout-unlocked-checkin", which IMHO is much more useful?
>>
>
> Yes, because when we wrote autoversioning, we had no lock support at
> the time. :-)
>
> Honestly, though, I don't know how we would map the
> 'checkout-unlocked-checkin' behavior to Subversion's concepts... ?
Ah. I forgot that SVN doesn't have checkout-in-place, right?
> What would this mean? Speficially, I don't understand how this
> checkout-unlocked-checkin behavior would benefit us, considering that
> MSOffice does
>
> LOCK nonexistentURL
...would create an empty locked resource...
> PUT 0-byte-file
...would check it out and update it with 0 byte content...
> PUT real-file
...would update the content again...
> UNLOCK URL
...would unlock it and check it back in (so a single version is created).
But this requires the server to support checkout-in-place.
Best regards, 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
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 21, 2005, at 9:27 AM, Julian Reschke wrote:
> Ben Collins-Sussman wrote:
>> On Mar 21, 2005, at 9:00 AM, Julian Reschke wrote:
>>>
>>> b) Even if it does, shouldn't the LOCK braces cause it to be a
>>> single checkin? (see
>>> <http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-
>>> version>, DAV:checkout-unlocked-checkin).
>>>
>> mod_dav_svn defines 'DAV:auto-version' to always be
>> 'DAV:checkout-checkin'.
>
> Is there a good reason why it doesn't implement
> "DAV:checkout-unlocked-checkin", which IMHO is much more useful?
>
Yes, because when we wrote autoversioning, we had no lock support at
the time. :-)
Honestly, though, I don't know how we would map the
'checkout-unlocked-checkin' behavior to Subversion's concepts... ?
What would this mean? Speficially, I don't understand how this
checkout-unlocked-checkin behavior would benefit us, considering that
MSOffice does
LOCK nonexistentURL
PUT 0-byte-file
PUT real-file
UNLOCK URL
?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Julian Reschke <ju...@gmx.de>.
Ben Collins-Sussman wrote:
>
> On Mar 21, 2005, at 9:00 AM, Julian Reschke wrote:
>
>>
>> b) Even if it does, shouldn't the LOCK braces cause it to be a single
>> checkin? (see
>> <http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-version>,
>> DAV:checkout-unlocked-checkin).
>>
>
> mod_dav_svn defines 'DAV:auto-version' to always be 'DAV:checkout-checkin'.
Is there a good reason why it doesn't implement
"DAV:checkout-unlocked-checkin", which IMHO is much more useful?
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 21, 2005, at 9:00 AM, Julian Reschke wrote:
>
> b) Even if it does, shouldn't the LOCK braces cause it to be a single
> checkin? (see
> <http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-version>,
> DAV:checkout-unlocked-checkin).
>
mod_dav_svn defines 'DAV:auto-version' to always be
'DAV:checkout-checkin'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Reschke <ju...@gmx.de> writes:
> C. Michael Pilato wrote:
> > Ben Collins-Sussman <su...@collab.net> writes:
> >
> >> * still interoperating with MS Office
> > ... with the unfortunately side effect of having every new file
> > creation look like *two* 0-byte PUTs (read, two commits of the same
> > empty file) -- one for the LOCK, and one for already-existing 0-byte
> > PUT that Office does. At least we can detect this fact, though, and
> > make the commit message read differently:
> > "WebDAV Autoversioning: Path '%s' reserved for locking with an
> > empty file."
> > "WebDAV Autoversioning: Modified '%s'.
>
> a) Does Office indeed to the 0-byte PUT (I'm not sure)?
Yes. Well, Office 2000 at least (didn't try 2003).
> b) Even if it does, shouldn't the LOCK braces cause it to be a single
> checkin? (see
> <http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-version>,
> DAV:checkout-unlocked-checkin).
Dunno about that. I do know that even if the DAV spec allows us to
"save up" all the changes on a resource into a single commit, that
doesn't mean our code is ready to support that behavior.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Julian Reschke <ju...@gmx.de>.
C. Michael Pilato wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
>
>> * still interoperating with MS Office
>
>
> ... with the unfortunately side effect of having every new file
> creation look like *two* 0-byte PUTs (read, two commits of the same
> empty file) -- one for the LOCK, and one for already-existing 0-byte
> PUT that Office does. At least we can detect this fact, though, and
> make the commit message read differently:
>
> "WebDAV Autoversioning: Path '%s' reserved for locking with an empty file."
> "WebDAV Autoversioning: Modified '%s'.
a) Does Office indeed to the 0-byte PUT (I'm not sure)?
b) Even if it does, shouldn't the LOCK braces cause it to be a single
checkin? (see
<http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-version>,
DAV:checkout-unlocked-checkin).
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 21, 2005, at 8:07 AM, C. Michael Pilato wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
>> * still interoperating with MS Office
>
> ... with the unfortunately side effect of having every new file
> creation look like *two* 0-byte PUTs (read, two commits of the same
> empty file) -- one for the LOCK, and one for already-existing 0-byte
> PUT that Office does. At least we can detect this fact, though, and
> make the commit message read differently:
>
> "WebDAV Autoversioning: Path '%s' reserved for locking with an
> empty file."
> "WebDAV Autoversioning: Modified '%s'.
>
Have you seen the sheer volume of commit messages that happen when
autoversioning is turned on? Having two commits when Office does a
'save as...' is a drop in the ocean. But heck, if you really care, go
for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> * still interoperating with MS Office
... with the unfortunately side effect of having every new file
creation look like *two* 0-byte PUTs (read, two commits of the same
empty file) -- one for the LOCK, and one for already-existing 0-byte
PUT that Office does. At least we can detect this fact, though, and
make the commit message read differently:
"WebDAV Autoversioning: Path '%s' reserved for locking with an empty file."
"WebDAV Autoversioning: Modified '%s'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
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
Re: Locking non-existent paths. Time to discuss.
Posted by Julian Reschke <ju...@gmx.de>.
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.
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
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
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.
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.
In reality, it seems like clients only ever do LOCK; PUT. How much
guessing do we need to do? How far should we go?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Julian Reschke <ju...@gmx.de>.
Ben Collins-Sussman wrote:
> On Mar 19, 2005, at 3:26 AM, C. Michael Pilato wrote:
>
>>
>> Say what?! Julian, will you please explain what is and isn't needed
>> support-wise across the following four areas of LOCKNULL support:
>>
>> - LOCK on a NULL resource
>> - UNLOCK on a NULL resource
>> - PROPFIND on a LOCKNULL resource
>> - Revelation of immediate LOCKNULL children of normal collections
>
>
> Ah, I think I see what Julian is saying.
>
> 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.
> (It sure would be nice to be able to read 2518bis! I can't find any
> link to it on www.webdav.org, nor does a google search bring it up. Is
> it some secret thing still?)
That's strange, Google located the copy on our page, see:
<http://greenbytes.de/tech/webdav/#draft-ietf-webdav-rfc2518bis>
And yes, webdav.org doesn't link to it and the draft hasn't been updated
for over 8 months. Please complain to the working group chairs and
authors :-)
Best regards, 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
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 19, 2005, at 3:26 AM, C. Michael Pilato wrote:
>
> Say what?! Julian, will you please explain what is and isn't needed
> support-wise across the following four areas of LOCKNULL support:
>
> - LOCK on a NULL resource
> - UNLOCK on a NULL resource
> - PROPFIND on a LOCKNULL resource
> - Revelation of immediate LOCKNULL children of normal collections
Ah, I think I see what Julian is saying.
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.
(It sure would be nice to be able to read 2518bis! I can't find any
link to it on www.webdav.org, nor does a google search bring it up. Is
it some secret thing still?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Reschke <ju...@gmx.de> writes:
> Ben Collins-Sussman wrote:
> > On Mar 18, 2005, at 3:31 PM, Julian Reschke wrote:
> >
> >>
> >> That's correct, it will fail. Back when the WG made the decision to
> >> deprecate lock-null resources, there was no evidence of clients
> >> actually relyong on the behaviour (if they did, they wouldn't work
> >> with IIS, as far as I can remember).
> >>
> > Well, we've already got minimal lock-null support working, so it's
> > probably easier to keep things as they are.
> > Mike has removed his support for listing lock-null children in
> > collections, since it's a lot of complexity for a feature that no
> > current clients use, and no future clients *should* use.
>
> But *that's* a feature that RFC2518bis aware clients *can* expect to work.
Say what?! Julian, will you please explain what is and isn't needed
support-wise across the following four areas of LOCKNULL support:
- LOCK on a NULL resource
- UNLOCK on a NULL resource
- PROPFIND on a LOCKNULL resource
- Revelation of immediate LOCKNULL children of normal collections
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Julian Reschke <ju...@gmx.de>.
Ben Collins-Sussman wrote:
>
> On Mar 18, 2005, at 3:31 PM, Julian Reschke wrote:
>
>>
>> That's correct, it will fail. Back when the WG made the decision to
>> deprecate lock-null resources, there was no evidence of clients
>> actually relyong on the behaviour (if they did, they wouldn't work
>> with IIS, as far as I can remember).
>>
>
> Well, we've already got minimal lock-null support working, so it's
> probably easier to keep things as they are.
>
> Mike has removed his support for listing lock-null children in
> collections, since it's a lot of complexity for a feature that no
> current clients use, and no future clients *should* use.
But *that's* a feature that RFC2518bis aware clients *can* expect to work.
> ...
Best regards, 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
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 18, 2005, at 3:31 PM, Julian Reschke wrote:
>
> That's correct, it will fail. Back when the WG made the decision to
> deprecate lock-null resources, there was no evidence of clients
> actually relyong on the behaviour (if they did, they wouldn't work
> with IIS, as far as I can remember).
>
Well, we've already got minimal lock-null support working, so it's
probably easier to keep things as they are.
Mike has removed his support for listing lock-null children in
collections, since it's a lot of complexity for a feature that no
current clients use, and no future clients *should* use.
So our plan will be:
--> Allow generic DAV clients to LOCK/PROPFIND/UNLOCK nonexistent urls.
--> Don't allow svn clients to 'svn lock' nonexistent urls, nor
lock schedule-add paths.
--> Allow 'svn unlock' to remove a lock on a nonexistent url.
The last bit probably isn't necessary, but it already works, and it's a
bit of insurance in case a DAV client crashes after locking a
nonexistent url. In practice, we expect these lock-null objects to
exist only for a fraction of a second, not long enough to interfere
with svn clients.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Julian Reschke <ju...@gmx.de>.
Ben Collins-Sussman wrote:
>
> On Mar 17, 2005, at 2:58 AM, Julian Reschke wrote:
>
>>
>> What *is* needed is the ability to LOCK an unmapped resource. However,
>> it's completely sufficient to implement this by creating an empty
>> placew holder resource.
>>
>> Thus,
>>
>> LOCK unmapped
>>
>> can be exactly the same as
>>
>> PUT unmapped
>> Content-Length: 0
>>
>> followed by
>>
>> LOCK unmapped
>>
>
> Julian: if we implement the above, the I understand that this sequence
> will work correctly (it's what MS office does):
>
> LOCK url
> --> nonexistent url means creation of locked, 0-byte file.
> PUT url
> --> 0-byte file is overwritten with real content>
Yep.
> But what about a client which runs
>
> LOCK url
> MKCOL url
>
> ?
>
> Won't the MKCOL fail if there's a 0-byte file in the way? Or what if
> the url is the target of a collection COPY/MOVE ?
That's correct, it will fail. Back when the WG made the decision to
deprecate lock-null resources, there was no evidence of clients actually
relyong on the behaviour (if they did, they wouldn't work with IIS, as
far as I can remember).
Best regards, 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
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 17, 2005, at 2:58 AM, Julian Reschke wrote:
>
> What *is* needed is the ability to LOCK an unmapped resource. However,
> it's completely sufficient to implement this by creating an empty
> placew holder resource.
>
> Thus,
>
> LOCK unmapped
>
> can be exactly the same as
>
> PUT unmapped
> Content-Length: 0
>
> followed by
>
> LOCK unmapped
>
Julian: if we implement the above, the I understand that this sequence
will work correctly (it's what MS office does):
LOCK url
--> nonexistent url means creation of locked, 0-byte
file.
PUT url
--> 0-byte file is overwritten with real content
But what about a client which runs
LOCK url
MKCOL url
?
Won't the MKCOL fail if there's a 0-byte file in the way? Or what if
the url is the target of a collection COPY/MOVE ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Max Bowsher <ma...@ukf.net>.
Ben Collins-Sussman wrote:
> On Mar 17, 2005, at 3:05 AM, C. Michael Pilato wrote:
>>>
>>> What *is* needed is the ability to LOCK an unmapped resource. However,
>>> it's completely sufficient to implement this by creating an empty
>>> placew holder resource.
>>
>> Well, that's certainly going to make useless a bunch of work I was
>> moments away from committing. :-(
>>
>
> Ok, then we have a new strategy!
>
> 1. make svn_fs_lock and svn_fs_attach_lock refuse to create locks on
> nonexistent resources. This is a 2-line change to the libsvn_fs
> 'switching' routine.
>
> 2. make mod_dav_svn check for a path's existence when creating a lock.
> If it doesn't exist, do an autoversioning commit of a 0-byte file on
> the spot.
Eeeek!
I admit to not having followed this thread very closely, but the above
proposal seems truly disgusting to me.
/me goes off to read history, in order to be able to effectively enter this
discussion.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 17, 2005, at 3:05 AM, C. Michael Pilato wrote:
>>
>> What *is* needed is the ability to LOCK an unmapped resource. However,
>> it's completely sufficient to implement this by creating an empty
>> placew holder resource.
>
> Well, that's certainly going to make useless a bunch of work I was
> moments away from committing. :-(
>
Ok, then we have a new strategy!
1. make svn_fs_lock and svn_fs_attach_lock refuse to create locks on
nonexistent resources. This is a 2-line change to the libsvn_fs
'switching' routine.
2. make mod_dav_svn check for a path's existence when creating a lock.
If it doesn't exist, do an autoversioning commit of a 0-byte file on
the spot.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Reschke <ju...@gmx.de> writes:
> Ben Collins-Sussman wrote:
> > Even though it's very late in the game, there are some critical
> > decisions we need to make about locking features. They tend to
> > cascade out from each other.
> > * Fact: libsvn_fs allows already locks on non-existent paths. This
> > feature exists to be interoperable with generic DAV clients. In DAV
> > parlance, such things are called 'lock-null' resources. That is:
> > they're 'null' resources (they don't exist), but are still locked.
>
> Lock null resources are deprecated in RFC2518bis (see [1] and [2]),
> and as far as I can tell, no generic client requires them.
>
> What *is* needed is the ability to LOCK an unmapped resource. However,
> it's completely sufficient to implement this by creating an empty
> placew holder resource.
Well, that's certainly going to make useless a bunch of work I was
moments away from committing. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking non-existent paths. Time to discuss.
Posted by Julian Reschke <ju...@gmx.de>.
Ben Collins-Sussman wrote:
> Even though it's very late in the game, there are some critical
> decisions we need to make about locking features. They tend to
> cascade out from each other.
>
> * Fact: libsvn_fs allows already locks on non-existent paths. This
> feature exists to be interoperable with generic DAV clients. In DAV
> parlance, such things are called 'lock-null' resources. That is:
> they're 'null' resources (they don't exist), but are still locked.
Lock null resources are deprecated in RFC2518bis (see [1] and [2]), and
as far as I can tell, no generic client requires them.
What *is* needed is the ability to LOCK an unmapped resource. However,
it's completely sufficient to implement this by creating an empty placew
holder resource.
Thus,
LOCK unmapped
can be exactly the same as
PUT unmapped
Content-Length: 0
followed by
LOCK unmapped
> ...
Best regards, Julian
[1]
<http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?url=http://tools.ietf.org/wg/webdav/draft-ietf-webdav-rfc2518bis/draft-ietf-webdav-rfc2518bis-06.txt#page-50>
[2]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.A.1.2>
--
<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