Sorry for top-posting, but although Brane is right, he's not being as helpful 
as he could.

Stefano, I had pretty much the same issue.  A workaround is to only do actions 
(other than Commit) on unlocked working copies.  That is, before doing a copy 
(in particular), make sure all locks are released.

The fix that worked for me was to update the server.  I downloaded the Wandisco 
server binaries (which are patched with the fix to this issue) and then copied 
mod_dav*.so to the modules directory of the Apache installation that we have 
actually working.  (Ideally, I'd just install and run the Wandisco binaries, 
but with our configuration it was easiest to get working by just doing the 
copy.)

Regards,

Geoff



        From: Branko Čibej
        Sent: Friday, 15 November 2013 18:09 PM
        To: users@subversion.apache.org
        Subject: Re: Method not allowed exception
        
        
        On 15.11.2013 07:47, Stefano Fraccaro wrote:
        

                Il 14/11/2013 22:35, Ben Reser ha scritto: 
                

                        Can you elaborate what method you're seeing method not 
allowed with?  Or if you 
                        were running a svn client what command you were 
running? 
                        

                TortoiseSVN > SVN Checkout 
                


                        The one case where we made such a change that comes to 
mind is with LOCK.  LOCK 
                        per the RFC can lock files that don't exist (otherwise 
known as an unmapped url 
                        or null resources). 
                        
                        http://webdav.org/specs/rfc4918.html#lock-unmapped-urls 
                        http://webdav.org/specs/rfc2518.html#rfc.section.7.4 
                        
                        We only support this when SVNAutoversioning is turned 
on and return a method 
                        not allowed error if this isn't turned on.  We felt 
that the method not allowed 
                        error was the logical error to return. 
                        
                        The other cases where we return method not allowed 
typically are cases where we 
                        don't allow that method on regular URLs unless 
auto-versioning is enabled. 
                        
                        


                We have an apache installation with subversion modules ( 
http://webserver/ ). 
                All our repositories are in svn subfolder ( 
http://webserver/svn/RepositoryName ) 
                If I checkout the url 
'http://webserver/badname/RepositoryName', subversion 
                return '405 Method not allowed' instead of '404 Url not found'. 
                
                
                Unexpected HTTP status 405 Method Not Allowed on 
'/badname/RepositoryName' 
                Additional errors: 
                PROPFIND request on '/badname/RepositoryName' failed: 405 
Method not allowed 
                


        I think you are mistaken, this error probably not returned by 
Subversion (since it's not configured on that location) but by the Apache HTTPd 
server itself. Most likely your server interprets the request as a PROPFIND on  
directory "badname" within the directory defined by the server configuration 
option  DocumentRoot. The default server configuration probably only allows GET 
requests on such paths; which makes a kind of sense, since the PROPFIND method 
is defined by the DAV protocol, not HTTP itself.
        
        -- Brane
        
        
        -- 
        Branko Čibej | Director of Subversion 
        WANdisco // Non-Stop Data 
        e. br...@wandisco.com


- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 


Reply via email to