Hi, Adrian, 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. - Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com<mailto:m.scha...@3s-software.com> | Web: http://www.3s-software.com <http://www.3s-software.com/> CoDeSys internet forum: http://forum.3s-software.com<http://forum-en.3s-software.com/> Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 Von: Adrian Smith [mailto:adrian.sm...@lightningfishgames.com] Gesendet: Mittwoch, 29. Februar 2012 12:25 An: users@subversion.apache.org Betreff: E200033: database is locked on svn update Just wondering if we can get some advice on this issue as it has become a head scratcher. All in house tools create a mutex lock around all svn commands named with the root path of the working copy. (This gets around multiple updates/commits being no longer supported in 1.7 command line, allowing multiple threads and applications to use the same repo). We also sleep within the mutex for 20 milliseconds after the svn process has been killed off. 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) We are using the command line “CollabNet Subversion Client 1.7.0.4 x64.exe”. While searching this seems similar to the “1.7.1: E200033: database is locked, executing statement 'RELEASE s0'” thread back in November. I can confirm we are definatly not calling svn.exe multiple times due to the mutex and sleep. Before we added the sleep this error was more frequent, I don’t suppose the svn.exe does post processing via an external process that keeps the database locked? Thanks in advance -Adrian
