On Tue, Jun 12, 2012 at 1:52 PM, Justin Case
<send_lotsa_spam_here_at_yahoo.com> wrote:
>> From: Johan Corveleyn <jcorvel_at_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.
According to Bert (sitting next to me at the svn hackathon in Berlin),
this has always been the case (also in 1.6), so he thinks it's not a
regression. There don't seem to be any behavior changes in 1.7.x that
should change any of this.
Can you run the scenario which you described, with an older version,
so that the working copy does not remain locked?
> 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...
Also according to Bert, svn cannot easily cleanup its locks when this
failure is happening. Some actions are still left in the "work_queue"
(moving the new file into place), which need to be run in order for
the wc database to get into a consistent state again. Cleanup does
that (among other things): steal any locks, and run what's left in the
work_queue.
--
Johan
Received on 2012-06-12 14:17:59 CEST