On Wed, Jun 13, 2012 at 12:20 PM, Justin Case
<send_lotsa_spam_here_at_yahoo.com> wrote:
> ----- Original Message -----
>
>> From: Ulrich Eckhardt <ulrich.eckhardt_at_dominolaser.com>
>>
>> Sorry, but I'm afraid I didn't get across what I wanted to say.
>
> Correct. Let me simplify again my test case:
> 1. I run svn update
> 2. svn update finds a file in use, aborts
> 3. I free the file, oops it seems I have to cleanup
>
> Why should I have to cleanup???
> svn update (see point 2) KNEW the file is in use, so instead of leaving locks around it could just have skipped that file and print a message that not everything have been updated.
The problem is that, at the point where svn runs into this locked
file, half of the work has already been done (the metadata in wc.db
has already been updated). The remaining work (moving the file into
place) is scheduled in a specific table called the work_queue. The
work_queue *must* be run to completion to get back into a valid state.
It cannot be rolled back (undoing the other part in wc.db), at least
not with the current design.
'svn cleanup' removes any working copy locks, and runs whatever is
left in the work_queue, thereby returning the working copy to a valid
state.
BTW, the work of moving the file into place has some sort of
"retry-loop", where it keeps retrying for a couple of seconds (to
account for anti-virus scanners and such, where the file is locked for
only a short time). But it can't keep waiting forever, so if the file
is locked for a long time, "update" will have to give up.
--
Johan
Received on 2012-06-13 14:13:42 CEST