On 8/24/2010 1:12 AM, Andrew Bennetts wrote:
> My quick guess is the lock's "info" file is empty somehow (which isn't
> supposed to happen). bzr probably should handle this situation more
> gracefully somehow... probably a conservative approach would be telling
> the user something strange has happened to the lock, and please use
> break-lock to clear it. (And probably involves fixing the lock breaking
> code to handle a corrupt/empty info file too).
>
Yeah. We tend to re-read the info file to make sure we broke the lock we
thought we did. (so we can catch if someone else breaks the lock, and
creates a new one in its place, etc.)
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/24/2010 1:12 AM, Andrew Bennetts wrote:
> My quick guess is the lock's "info" file is empty somehow (which isn't
> supposed to happen). bzr probably should handle this situation more
> gracefully somehow... probably a conservative approach would be telling
> the user something strange has happened to the lock, and please use
> break-lock to clear it. (And probably involves fixing the lock breaking
> code to handle a corrupt/empty info file too).
>
Yeah. We tend to re-read the info file to make sure we broke the lock we
thought we did. (so we can catch if someone else breaks the lock, and
creates a new one in its place, etc.)
John
=:->
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org/
zykwACgkQJdeBCY SNAAO// ACeI9O05yDV3gia PWosM0vdcHBM koe0U6BPeJrK9t/ Pl
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkx
4BEAoJxrEf62f5Q
=CSRj
-----END PGP SIGNATURE-----