[Returning the discussion to the devlist where it belongs.]
Thanks for the info. It's been a while since I worked on our WebDAV
autoversioning logic. I *definitely* don't have a new enough version of Web
Folders available. (My personal boxen still run Win2k!) I think you've
given me enough reason to believe there's a real problem to be researched
here, so please feel free to file an issue in our issue tracker regarding
this problem (at http://subversion.tigris.org/issue-tracker.html).
I trust that by "you may receive", you mean "you, the dev-list, may
receive". You might not always get immediate response from the dev-list,
but the beauty of a mailing list is that your information is maintained
indefinitely for future archaeological benefit. Many of us flag incoming
mails for processing later, as there's always the chance that someone else
can spend the time to respond right now even if we really can't.
Pauli Vaahterametsä wrote:
> Yes. The default lock timeout is 3 minutes and in about 2 minutes Word
> will try to refresh the lock and fail, and the open document will change
> into a read only mode.
> Of course you should have a recent (12.x, Rosebud) version of Web Folders
> installed before trying to use MS Office for any real WebDAV debugging
> operations. The problem should exist also with earlier versions though, as
> I see it as a server side problem.
> If you have difficulties reproducing the problem I can provide all
> information you need. I'm running the server on a Win32 platform.
> (Btw, now that I've gotten a communication contact to someone there, you
> may receive many other bug reports in the future. :-) )
>> Pauli, is reproducing the problem you are seeing as simple as, say,
>> a Word document directly from a Subversion DAV share and letting it sit
>> some amount of time greater than the originally request lock timeout
>> Pauli Ojanperä wrote:
>>> I was investigating a Subversion locking bug reported here:
>>> My own experience of the bug tells that any tries of a MS Office
>>> to refresh its lock do fail. By running "svnadmin lslocks repo" we can
>>> confirm that the initial locking succeeds. However, mod_dav is not
>>> the information of the lock token's existence, and fails on the "If:"
>>> precondition manifested in the lock refresh request header.
>>> Apache logs say:
>>> Could not LOCK /repo/nnn.txt due to a failed precondition (e.g. other
>>> locks). [412, #0]
>>> The precondition(s) specified by the "If:" header did not match this
>>> resource. At least one failure is because: a State-token was supplied,
>>> it was not found in the locks on this resource. [412, #0]
>>> It seems to me that the commit linked below causes mod_dav_svn to be
>>> unable to confirm the precondition (the existence of a locktoken) to
>>> continue fulfilling a lock refresh request.
>>> What do you think?
>> C. Michael Pilato <cmpilato_at_collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2009-10-09 22:57:43 CEST