>> 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