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