> From: Johan Corveleyn <jcor...@gmail.com> > > cleanup' (cleanup is the only command that will unconditionally remove > these locks, so you should only run it if you're sure there is no > other command running concurrently, and those locks are "stale locks" > left by other interrupted commands). > [...] > I don't follow. You mean that svn 1.6 didn't request cleanup? What is > the exact set of commands, and the exact error messages you're > getting?
Thank you for the explanation. I was also expecting what Andreas said - the update command should be able to manage its own locks. It's not like it met some unknown SVN locks, but the file was simply in use. I also see this behavior coming only recently since I upgraded to TortoiseSVN 1.7.something - I cannot tell you which commands the client sends, or which version of svn it was previously using, just that the Tortoise guys said it's not their ball. Here's my very simple test case: - open a text file in Word (that will lock it) - from another machine change and commit the text file - update from the Word machine, there comes the expected error: Update Can't move 'C:\mydir\.svn\tmp\svn-CCAED25B' to 'C:\mydir\somepath\test.txt': Access is denied. - close Word, the file is free as a bird - update again, there comes the unexpected error: Update Previous operation has not finished; run 'cleanup' if it was interrupted Please execute the 'Cleanup' command. - cleanup works, all fine and dandy In any case, I certainly hope the new version doesn't expect from me, the user, telling it whether the lock is a stale one or if there's some other command hanging on it... Many thanks, JC
