Cleanup needed after failed update

Hi all,
this is something new for me (TortoiseSVN 1.7.7 with Subversion 1.7.5 on Windows XP):
- I try to update something when a file is in use,
- update understandably fails, it cannot overwrite that file. Fine.
- BUT I cannot update again, I have to cleanup first!
Before days (months?) the cleanup wasn't requested. Is that locked file such a big fuss that it corrupts everything? Could the client just leave it 
unupdated and abort - like it did before? Or is there a wrong setting of mine? I asked already on the Tortoise mailing list and they meant it's an issue of Subversion concern...

Thanks for any suggestions,
JC

Hello all,

did I just ask a stupid question :) or nobody has any idea what's going wrong here?

Thank you very much for your patience,
JJ----- Original Message -----
> From: Justin Case 
> 
> Hi all,
> this is something new for me (TortoiseSVN 1.7.7 with Subversion 1.7.5 on Windows 
> XP):
> - I try to update something when a file is in use,
> - update understandably fails, it cannot overwrite that file. Fine.
> - BUT I cannot update again, I have to cleanup first!
> Before days (months?) the cleanup wasn't requested. Is that locked file such 
> a big fuss that it corrupts everything? Could the client just leave it 
> unupdated and abort - like it did before? Or is there a wrong setting of mine? I 
> asked already on the Tortoise mailing list and they meant it's an issue of 
> Subversion concern...
> 
> Thanks for any suggestions,
> JC
>

On Wed, Jun 6, 2012 at 1:14 PM, Justin Case
 wrote:
> Hi all,
> this is something new for me (TortoiseSVN 1.7.7 with Subversion 1.7.5 on Windows XP):
> - I try to update something when a file is in use,
> - update understandably fails, it cannot overwrite that file. Fine.This is indeed normal, I think.

> - BUT I cannot update again, I have to cleanup first!

This seems normal too. Before doing anything, 'svn update' will lock
the working copy (to prevent any concurrent svn actions from messing
with it while it's updating). If 'svn update' fails midway through,
the locks will be left. These need to be removed by running 'svn
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).

> Before days (months?) the cleanup wasn't requested. Is that locked file such a big fuss that it corrupts everything?

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?

On Tue, 12 Jun 2012 12:26:34 +0000, Johan Corveleyn wrote:
...
> > - BUT I cannot update again, I have to cleanup first!
> 
> This seems normal too. Before doing anything, 'svn update' will lock
> the working copy (to prevent any concurrent svn actions from messing
> with it while it's updating). If 'svn update' fails midway through,
> the locks will be left.I'd say, that depends. If svn dies horribly via core dump or being
'kill -9'ed, or the whole machine losing power, then ok.

But here it is a failure that svn itself detects and handles, and
this handling should IMHO include releasing the lock after any
other necessary cleanup. (After all, that running svn instance
still knows that it is its lock, unlike us who then need to
run 'svn cleanup'.) If 'svn up' can't know how to handle,
how should 'svn cleanup' later?

Andreas

> From: Johan Corveleyn 

>
> 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

On Tue, Jun 12, 2012 at 1:52 PM, Justin Case
 wrote:
>> From: Johan Corveleyn 
>
>>
>> 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.

Am 12.06.2012 13:52, schrieb Justin Case:
> 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...Put that into the context of the error message:> Update
> Previous operation has not finished; run 'cleanup' if it was
> interrupted
> Please execute the 'Cleanup' command.Only you (the user) knows "if it was interrupted" or is maybe still
running! I would say that this message could be improved[0], but
otherwise the behaviour when encountering a lock is nothing that could
be improved much, it really relies on the user to make an informed
decision. This is not different from older SVNs though, only that the
location in only one spot (central metadata location) hopefully improved
the cleanup speed.

Other than that, update could probably fail without keeping the working
copy locked. Depending on the internals, this could be complex though,
or leave the working copy in a state of mixed revisions.

Uli

[0] "Previous operation has not finished; Wait for it to finish or run
'cleanup' if it was interrupted." In no case should it suggest running
cleanup unconditionally, as it does now.

**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.

> From: Ulrich Eckhardt 
>
> Only you (the user) knows "if it was interrupted" or is maybe still
> running! I would say that this message could be improved[0], butI beg to differ: the operation which interrupted itself because it found a file in use knows very well that it was interrupted. So, it would be in the best position to do something instead of just quitting graciously. You later suggestion "leave the working copy in a state of mixed revisions" is exactly what I as user would expect from it: "hey, error! I couldn't finish my job bcoz file X is in use, just close the other app then try updating again". 
And I could swear it was like this before, I never had to cleanup even though I always forgot DLLs in use... I just can't test it because the only machine with a 1.6 SVN I have is a server and doesn't have Word (and will never have) - any idea how to mark a file "in use" on Windows Server 2003? Notepad/Wordpad doesn't cut it.

Thanks a lot,
JC

Hi,On Tue, Jun 12, 2012 at 06:43:52AM -0700, Justin Case wrote:
> > From: Ulrich Eckhardt 
> >
> > Only you (the user) knows "if it was interrupted" or is maybe still
> > running! I would say that this message could be improved[0], but
> 
> I beg to differ: the operation which interrupted itself because it found a file in use knows very well that it was interrupted. So, it would be in the best position to do something instead of just quitting graciously. You later suggestion "leave the working copy in a state of mixed revisions" is exactly what I as user would expect from it: "hey, error! I couldn't finish my job bcoz file X is in use, just close the other app then try updating again".Dito. That context knows that it encountered a problem and knows best what
it's been doing, thus it's obviously within its own scope and *responsibility*
that it should be doing (or at least attempting to do) proper cleanup.
Necessity of "svn cleanup" should definitely be relegated to exceptional use cases,
since it's a problematic *foreign* intrusion into the lock-shared processing.
Well, so much for idealistic speak - I don't know SVN implementation
specifics which might go against implementing it like that.

> And I could swear it was like this before, I never had to cleanup even though I always forgot DLLs in use... I just can't test it because the only machine with a 1.6 SVN I have is a server and doesn't have Word (and will never have) - any idea how to mark a file "in use" on Windows Server 2003? Notepad/Wordpad doesn't cut it.

Probably see exclusive sharing modes (flags at Win32 CreateFile() API).
Either code up a quick app which locks a file, or do an internet search on
the terms encountered in CreateFile() docs and thus discover some app
which already does that, too.

HTH,

Andreas Mohr

Am 12.06.2012 15:43, schrieb Justin Case:
>> From: Ulrich Eckhardt 
>> 
>> Only you (the user) knows "if it was interrupted" or is maybe
>> still running! I would say that this message could be improved[0],
>> but
> 
> I beg to differ: the operation which interrupted itself because it
> found a file in use knows very well that it was interrupted.Yes, probably, unless it was killed so quickly that it couldn't even cry
for help any more, which e.g. happens if you cut the power or use "kill
-9" on POSIX systems.

However, I was referring to the error message that is given if you e.g.
run "svn update", which knows nothing about previously interrupted or
still running operations! The only thing it knows is that there is a
lock and that this indicates an unfinished operation. In that case, SVN
really must let the user decide whether something was interrupted or
whether something is still running.

Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.

----- Original Message -----
> From: Ulrich Eckhardt 
> Yes, probably, unless it was killed so quickly that it couldn't even cry
> for help any more, which e.g. happens if you cut the power or use "kill
> -9" on POSIX systems.We're not talking here about natural catastrophes, but about a file which was in use when tried to update :)
So the solution would be with the first update, the one which fails with file in use - it could revert the temp file creation and just leave the used file and the following tasks un-updated, then exit saying so.
Then the next update will just have to pick up the remaining tasks, no need to cleanup.

Of course if the first update just disappeared because of tsunamis, the revert will also not happen and a cleanup will be needed. That's fine and understandable.

Hm?
JC

Am 12.06.2012 16:49, schrieb Justin Case:
> ----- Original Message -----
>> From: Ulrich Eckhardt  Yes,
>> probably, unless it was killed so quickly that it couldn't even
>> cry for help any more, which e.g. happens if you cut the power or
>> use "kill -9" on POSIX systems.
> 
> We're not talking here about natural catastrophes, but about a file
> which was in use when tried to update :) So the solution would be
> with the first update, the one which fails with file in use - it
> could revert the temp file creation and just leave the used file and
> the following tasks un-updated, then exit saying so. Then the next
> update will just have to pick up the remaining tasks, no need to
> cleanup.Sorry, but I'm afraid I didn't get across what I wanted to say. There is
an SVN process, and that process finds a lock on a working copy[0]. It
now must rely on the user to determine whether this lock is stale or
not. In this specific context, I really don't care why the lock was
there and whether it should be there or not, that is a related but
different issue. See the last paragraph of my initial mail in this
thread for my opinion on this different issue.

 (c:

Uli

[0] Just to get this clear: A lock on a working copy is not the same as
denied access to a file during an update! Maybe that is the reason of
the confusion between us?
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.

----- Original Message -----

> From: Ulrich Eckhardt 
> 
> 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.
JC

On Wed, Jun 13, 2012 at 6:20 AM, Justin Case 
> wrote:

> ----- Original Message -----
>
> > From: Ulrich Eckhardt 
> >
> > 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.
> JC
>To detect a "locked file" as a safe change to reject and fail on, wouldn't
Subversion have to know quite a bit about the underlying filesystem? This
can be surprisiingly difficult, and is partly why lock files exist, to
abstract that subtle knowledge into a more tangible "no, we're not kidding,
leave this alone while we're doing atomic operations" stage. I'm not saying
it's infeasible, just potentially more comlicated than you may realize.

On Wed, Jun 13, 2012 at 12:20 PM, Justin Case
 wrote:
> ----- Original Message -----
>
>> From: Ulrich Eckhardt 
>>
>> 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.

> From: Johan Corveleyn 
> 
> 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.Ah I see now. Too bad then. 
Was it always that way, no rollback possible? Or maybe the ordering of operations used to be different so it gave up before updating the db? Because really I didn't run into this cleanup need until recently...
Many thanks,
JC

On Wed, Jun 13, 2012 at 2:25 PM, Justin Case
 wrote:
>
>
>> From: Johan Corveleyn 
>>
>> 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.
>
> Ah I see now. Too bad then.
> Was it always that way, no rollback possible? Or maybe the ordering of operations used to be different so it gave up before updating the db? Because really I didn't run into this cleanup need until recently...
> Many thanks,The wc.db and work_queue are part of WC-NG (with centralized
metadata), which was introduced with 1.7. The previous working copy
design was very different (small metadata files scattered around in
the .svn directories in each subdirectory of the working copy).

It's possible that 1.6 could exit more cleanly in this situation,
without leaving locks, I'm not sure (and I don't have a 1.6 laying
around here right now). Maybe you or someone else on this list can
verify this.

But certainly all 1.7.x versions should have the same problem as what
you're seeing now (at least I don't know of any change in the 1.7.x
line that could have changed this).

On Wed, Jun 13, 2012 at 02:12:47PM +0200, Johan Corveleyn wrote:
> On Wed, Jun 13, 2012 at 12:20 PM, Justin Case
>  wrote:
> > 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.So, the awkward "external svn cleanup" requirement
is indeed "simply" a matter of implementation weakness in
"atomic transaction processing" (i.e. application of a collected change
only after *all* interim steps have been successfully completed in a
*temporary* working area,
or alternatively [when unable to implement it in such a definitely desireable way],
a properly working rollback mechanism for partially modified data).> '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.Yeah, and ideally that currently running command itself would:
- either instantiate the modified dataset only after everything
  has been successfully completed
  (data modification could be carried out atomically
  by an atomic rename of old dir vs. new dir or some such)
- or execute a properly working rollback mechanism

But as said before, that's possibly quite hard to achieve
in light of an existing possibly multi-layered implementation
which does things differently
(and which possibly has some existing binding contracts to userspace
which might get broken by a rewrite,
perhaps special wc.db behaviour or so).

Andreas Mohr

----- Original Message -----

> 
> But as said before, that's possibly quite hard to achieve
> in light of an existing possibly multi-layered implementationNo idea what you mean with multi-layers - wc.db and such are internal issues of svn, of which nobody above should be made aware. I think. At the end of the day, for me as enduser the upgrade to 1.7 was a step backward (same feeling like Android 4). I downgraded in the meantime my computers to 1.6, simpler life this way.

JC

On Wed, Jun 13, 2012 at 7:12 AM, Johan Corveleyn  wrote:
>
>> 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.So a process that is supposed to be atomic isn't...> '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.So how is the user supposed to know better about what to do next than
the program that is aware of the situation?

On Wed, Jun 13, 2012 at 10:17:02AM -0500, Les Mikesell wrote:
> On Wed, Jun 13, 2012 at 7:12 AM, Johan Corveleyn  wrote:
> > 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.
> 
> So a process that is supposed to be atomic isn't...This is not about atomic operations. Modifications made to wc.db state
and on-disk files are not synchronised in an atomic fashion.

The work queue is like a filesystem "journal". It collects changes that need
to be applied to sync the working files on disk (which users edit) with the
state of meta-data in wc.db. Usually, the work queue is run when an operation,
or some subset thereof, completes. 'svn cleanup' runs the work queue, too.
A write-lock on the WC usually implies that some other process is currently
making modifications to the WC and might be running work queue items.

I don't know if Justin's particular case could somehow be detected and
handled in a more automated fashion. But it would be nice if svn did this.
Justin, if you care strongly about this, please add an entry to our issue
tracker[1] that points at this thread in the archives and summarizes the
problem. Maybe somebody will find time to look into this in detail some day.
Anyone is welcome to do so, including anyone who has participated in this
thread so far, and submit concrete suggestions or even patches that address
this issue. Thanks!

[1] see http://subversion.apache.org/reporting-issues...

Stefan Sperling  writes:

> I don't know if Justin's particular case could somehow be detected and
> handled in a more automated fashion. But it would be nice if svn did this.
> Justin, if you care strongly about this, please add an entry to our issue
> tracker[1] that points at this thread in the archives and summarizes the
> problem. Maybe somebody will find time to look into this in detail some day.
> Anyone is welcome to do so, including anyone who has participated in this
> thread so far, and submit concrete suggestions or even patches that address
> this issue. Thanks!There is a 1.7 bug:

http://subversion.tigris.org/issues/show_bug....

that fails to remove locks that should be removed.

I'm not sure whether that applies to Justin's particular case because
that's only a problem if the lock gets released between the original
workqueue run and the second workqueue run.  That's a very small
window--in most cases both runs see the lock and the bug does not apply.

There is also a 1.6 bug:

http://subversion.tigris.org/issues/show_bug....

that removes locks that should remain.

I think it is likely that Justin is seeing the buggy 1.6 behaviour.  In
some circumstances this buggy behaviour will not cause a problem but in
other circumstances it will corrupt the working copy.

----- Original Message -----

> 
> I'm not sure whether that applies to Justin's particular case because
> that's only a problem if the lock gets released between the original
> workqueue run and the second workqueue run.  That's a very small
> window--in most cases both runs see the lock and the bug does not apply.I don't think so - my problem comes if the DLL file to be replaced happens to be in use at the time when I do the svn update. 
Please guys, don't keep using the word "locks" then throwing it back at me: I'm NOT EXPERIENCING LOCKS, just a regular file being in use in Windows. That's most probably not a svn lock, although I actually have no idea what a svn lock actually is - I just don't want to do a cleanup each time svn fails to update a file in use.
JC

Guten Tag Justin Case,
am Samstag, 16. Juni 2012 um 03:33 schrieben Sie:

> Please guys, don't keep using the word "locks" then throwing it
> back at me: I'm NOT EXPERIENCING LOCKS, just a regular file being in
> use in Windows.Calm down, there's more than one type of a lock and just because you
don't know which one the svn developers are talking about at the
moment, they are not throwing anything. Some examples: The running DLL
is locked by Windows, there are svn locks setup by an end user using
GUI or CLI, svn is internally using locks for changing data, SQLite
uses locks when accessing/changing it's database aka wc.db and so on.

Mit freundlichen Grüßen,

Thorsten Schöning

On Sat, Jun 16, 2012 at 01:55:18AM +0100, Philip Martin wrote:
> There is also a 1.6 bug:
> 
> http://subversion.tigris.org/issues/show_bug....
> 
> that removes locks that should remain.
> 
> I think it is likely that Justin is seeing the buggy 1.6 behaviour.  In
> some circumstances this buggy behaviour will not cause a problem but in
> other circumstances it will corrupt the working copy.Right. I was thinking some more about this last night, and failed to
wrap my head around the idea that the 1.6 wc log framework was apparently
able to rename a file onto an open file on Windows, while a 1.7 wc work
queue fails to do so.

AFAIK open files cannot be deleted on Windows. So either the file was closed
at the time the 1.6 wc log was run, or the 1.6 wc log failed to actually
update the on-disk data.

I believe if the file then committed from the same working copy, this could
lead to some already committed changes accidentally being reverted, could it
not? It would be hard to notice such a problem since the file in question
is a dll where errors in the committed changeset cannot easily be seen.

In that light it seems 1.6 misbehaved whereas 1.7 now does the right thing
by enforcing install of the on-disk file via 'cleanup'.

So... my advice to Justin would be to close all files before an update,
with any version of Subversion, to avoid the above problem. Or keep using
'cleanup'. Or switch to an operating system where open files can be deleted.

However, if we could somehow detect this windows-specific problem case and
work around it, I'd very much like svn to do this. But I don't know how we
could, and I myself certainly won't do any voluntary development work on
the Windows platform, thank you very much :)

----- Original Message -----

> From: Stefan Sperling 
> 
> AFAIK open files cannot be deleted on Windows. So either the file was closed
> at the time the 1.6 wc log was run, or the 1.6 wc log failed to actually
> update the on-disk data.No no no :) neither nor. 
1.6 just tested the file _before_ updating the wc (wild guess, I have no idea about internals) then gave up. So I had to rerun svn update later when the file wasn't in use anymore. This is not misbehaving, imho.
JC

Johan Corveleyn <jcorvel <at> gmail.com> writes:
> '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.One thing which could help in this case, rather than just retrying for N seconds 
would be to provide a callback function so that a GUI client like TSVN could 
display a message saying that file X is already open, giving you a chance to 
close it and retry the operation.

Simon