subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Case <send_lotsa_spam_h...@yahoo.com>
Subject Re: Cleanup needed after failed update
Date Tue, 12 Jun 2012 11:52:01 GMT
> From: Johan Corveleyn <jcorvel@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


Mime
View raw message