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 :)
Received on 2012-06-16 12:41:41 CEST