> > + # Around trunk@1581815 refreshing of DAV lock fails with error
> > + # '412 Precondition Failed'
> You say it starts to fail at r859583 so how is 1581815 relevant?
I've just tried to say that problem is still actual at r1581815.
Philip Martin writes:
> Sergey Raevskiy writes:
>
>> What actually happens here: Excel tries to refresh existing lock using
>> an "If" header (see section 7.8 of RFC 2518 [1]). The supplied lock
>> token is valid but server responds with '412 Precondition Failed'
>> instead of '200 OK'. Excel
Sergey Raevskiy writes:
> What actually happens here: Excel tries to refresh existing lock using
> an "If" header (see section 7.8 of RFC 2518 [1]). The supplied lock
> token is valid but server responds with '412 Precondition Failed'
> instead of '200 OK'. Excel tries to obtain a new lock on o
Sergey Raevskiy wrote on Wed, Apr 02, 2014 at 13:28:04 +0400:
> There is a hack in mod_dav_svn needed for support concept of lock stealing:
>
> [[[
> /* The Big Lie: if the client ran 'svn lock', then we have
>to pretend that there's no existing lock. Otherwise mod_dav will
>throw '403 Lo
Hi!
I've discovered another problem related to locks.
Environment:
Server:
Windows Server 2008 R2 SP1
Subversion 1.8.8,
Apache HTTP Server 2.2.25.
Autoversioning is enabled in Apache HTTP Server's settings:
http://svnbook.red-bean.com/en/1.8/svn.webdav.autoversioning.html
5 matches
Mail list logo
