On 8/19/2010 10:57 PM, Philip Peitsch wrote:
> Public bug reported:
>
> I had an instance where the .bzr\checkout\lock\held folder was not
> removed (I don't know how this happened... potentially virus scanner
> related). I found subsequent write calls (e.g., bzr shelve, bzr up)
> would simply hang indefinitely with no error messages or timeouts,
> including no warnings about existing locks. This was on bzr 2.1.1.
>
> I retried on 2.2.0 (by simply manually creating the held folder) and it
> crashes with "UnboundLocalError: local variable 'lock_url' referenced
> before assignment". I'm not to worried by that behaviour however, as it
> at least does something after a few seconds as opposed to 2.1.1
>
> ** Affects: bzr
> Importance: Undecided
> Status: New
>
By default, we waited 5 minutes for the lock to be released before we
would fail. However, we should have been warning you that the lock was
present.
The latter failure looks like code that wanted to read the 'info' file
was failing to handle it properly when the file was not present.
Though this also might have been the problem in 2.1, since we would use
the information there to let you know who held the previous lock.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/19/2010 10:57 PM, Philip Peitsch wrote: lock\held folder was not
> Public bug reported:
>
> I had an instance where the .bzr\checkout\
> removed (I don't know how this happened... potentially virus scanner
> related). I found subsequent write calls (e.g., bzr shelve, bzr up)
> would simply hang indefinitely with no error messages or timeouts,
> including no warnings about existing locks. This was on bzr 2.1.1.
>
> I retried on 2.2.0 (by simply manually creating the held folder) and it
> crashes with "UnboundLocalError: local variable 'lock_url' referenced
> before assignment". I'm not to worried by that behaviour however, as it
> at least does something after a few seconds as opposed to 2.1.1
>
> ** Affects: bzr
> Importance: Undecided
> Status: New
>
By default, we waited 5 minutes for the lock to be released before we
would fail. However, we should have been warning you that the lock was
present.
The latter failure looks like code that wanted to read the 'info' file
was failing to handle it properly when the file was not present.
Though this also might have been the problem in 2.1, since we would use
the information there to let you know who held the previous lock.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkx ymAMACgkQJdeBCY SNAAPmQQCgxFMwF k00aP4yuugR7Rcg Pl+E lF5DrS3jvi7rC1O u7
xowAnjAy9zsobsI
=HRPN
-----END PGP SIGNATURE-----