Re: Cleanup needed after failed update
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 -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Cleanup needed after failed update
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.cgi?id=4196 > > 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 :)
Re: Cleanup needed after failed update
- 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
Re: Cleanup needed after failed update
Johan Corveleyn 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
