Locking problem (showstopper)

[Steve Bennett]

> -----Original Message-----
> > 2) I'm not sure that I understand how to reproduce your problem.
> > If it's repeatable error, can you provide exact sequence of actions?
> 
> I don't have an exact repro case yet. It tends to happen after some
> hundreds
> or thousands of commits, which takes a few hours. I hope to get a better
> idea of what triggers it. In the meantime I've hacked the source to remove
> the prompt for breaking the lock, and I'm just breaking the lock and
> retrying whenever it occurs. It seems to work...?

Just thought I would add that I have now improved my process by pausing for
3 seconds prior to every bzr action, and now the locking problem *never*
occurs. In other words, this sometimes (1 time in 1000) fails:

<modify file>
bzr commit --local
bzr update
bzr commit
bzr: ERROR: Permission denied: "C:/bzr/Tlib90/.bzr/repository/lock/held":
[Error 32] The process cannot access the file because it is being used by
another process

whereas this never fails:
<modify file>
bzr commit --local
<pause 3 seconds>
bzr update
<pause 3 seconds>
bzr commit
<pause 3 seconds>


While discussing this issue with someone who knows a bit about Windows, he
said that Windows doesn't guarantee that you can delete a file immediately
after a process using that file terminates. Apparently Windows attempts to
cache files and let you close then immediately reopen a file with no
performance hit.

The problem as it stands is that if that process that attempts to delete the
.lock file fails, then that file will sit around *forever*. Perhaps if it
fails to delete the .lock file, it could at least create a .unlock file or
something, and future calls to bzr will check for that file, and attempt to
delete both it and the .lock file if found. Or something. :)

Steve