On 2/25/07, Backup e-mail <bckemail@yahoo.com> wrote:
> Perhaps I'm wrong, but if I watch the trace of the LOCK request I see that
> it ends while informing that it can not find the .svn/log (directory/file).
> Isn't that significant in this context?
No, it's not significant at all. .svn/log is a temporary journal that
the working copy creates to 'get work done' When changes need to be
made to the working copy, the actions are first journaled in
.svn/log, then executed from the log, then the log is removed. The
journaling aspect allows the client to be interrupted; when the user
runs 'svn cleanup', it finishes executing any leftover log journals.
> Isn't that important or can it do without?
>
In this case, it's totally irrelevant. Notice that the server has
*already* sent a 405 error, and the client is writing it to the
screen. The two strace commands following that are just routine
cleanup checks: "delete .svn/log if present" and "delete the
'lockfile' if present". (The .svn/lock file is just marker that means
"I'm working within this .svn/ area now".... it prevents more than one
client process from trying to change an .svn/ area at once.)
The issue is still a question of why the server is denying your
request. Client-side bookkeeping operations do not affect the
server's configuration. :-)
If you want to trace something useful, try making the repository
available outside of SSL, and do a network trace of the LOCK
request/response using wireshark.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 25 14:33:11 2007