[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-21 16:56:43 CET

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
Received on Mon Mar 21 17:04:25 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.