>> 1. It shows locked status even other people not being used it in
>> Lock.
>>
>> 2. I will have to run CleanUp command , Why?
>>
Good morning,
I ran into this problem recently, too.
First: So far I can tell that there might be some circumstances where the
working copy is left locked on svn update/status/add/remove operations even
though there was no error that caused a crash of svn. Thus all locks *should
be* released once svn terminates.
Second: I can confirm that it is not a problem with tortoisesvn since this
happened to me while using a self-written svn frontend that interacts with
svn on the commandline.
Since it did not happen very frequently to me I did not try to reproduce the
error and - to be honest - I don't bother because it happened only once or
twice.
But there is indeed some noise in the subversion-users mailing list
regarding this problem. I'm going to quote one:
On 29.02.2012 12:40 'Adrian Smith' wrote:
>Even with all of the precautions above on a single multi threaded
>application we see the error below on average seven times in two thousand
>individual updates.
>
>svn: E155004: Working copy '*' locked
>svn: E200033: database is locked
>svn: E200033: database is locked
>svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
>details)
On 29.02.2012 15:21 'Markus Schaber' responded:
>Two ideas:
>- Some antivirus "live" scanner might lock the working copies.
>- Some other background process like windows search indexer, or
>TortoiseSVNs TSvnCache.exe might access the working copies in parallel.
Could something like this be your problem? Meaning: are you accessing your
working copy concurrently from different threads/processes? There might be
some interesting race conditions treasured in 1.7.X that haven't been found
yet, as Markus Schaber already mentioned on 14.02.2012 12:57:
>When SVN 1.7 working copies are accessed concurrently (different Threads or
Processes), I
>often get SVN_ERR_WC_LOCKED.
Cheers,
Dominik
Received on 2012-03-26 08:46:18 CEST