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

Re: Cleaning up XFails: locks-test.exe 9 and 10

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 8 Feb 2011 10:17:02 -0500

On Mon, Feb 7, 2011 at 4:14 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 02/07/2011 03:44 PM, Philip Martin wrote:
>> Paul Burba <ptburba_at_gmail.com> writes:
>>
>>> Do "DAV clients sometimes LOCK non-existent paths, as a way of
>>> reserving names"?  I'm not sure exactly what that means, does anyone
>>> have an inkling?
>>
>> In subversion/mod_dav_svn/lock.c:append_locks the code does a PUT of a
>> 0-byte file when an attempt is made to lock a non-existant file.  You
>> need SVNAutoversioning enabled and you need to be using a non-Subversion
>> client.  It is possible to trigger this using cadaver:
>>
>> $ svnadmin create repo
>> $ ln -sf /bin/true repo/hooks/pre-lock
>> $ cadaver http://localhost:8888/obj/repo
>> dav:/obj/repo/> lock f
>> Locking `f': succeeded.
>> dav:/obj/repo/> quit
>> $ svnlook tree repo
>> /
>>  f
>
> While generic DAV clients can "LOCK non-existent paths", Subversion's
> behavior is to immediate turn those into non-non-existing paths. :-)  We
> decided long ago that we didn't want to support the so-called "LOCK-NULL
> resources" (locks on non-existent paths), so the code cheats to avoid this.
>  As such, the tests which attempt to validate that we do support these can
> be tossed, in my opinion.
>
> And I'd say you could toss the directory locking test, too.  The problem
> space was large enough that we bailed on supporting it in the first release
> of the locking support.  So if we ever do decide to support this, we'll have
> to design a full suite of tests with coverage that's advanced enough to
> match the complexity of the problem space.

Thanks for the info, removed those tests in r1068436.

Paul
Received on 2011-02-08 16:17:42 CET

This is an archived mail posted to the Subversion Dev mailing list.