I'm not sure what to do with this bug. I'm close to saying it's a server bug or quirk and bzr is not doing anything wrong, especially as Vincent reports he can't reproduce it.
Releasing the read lock before acquiring the write lock as proposed in the original patch would be wrong. The contract of this locking code is that you can write-lock a file that was previously read locked.
Eventually, per bug 98836, we'd like to get rid of the use of os locks for dirstates and repositories, which will avoid the area that's causing trouble with this bug.
I'm not sure what to do with this bug. I'm close to saying it's a server bug or quirk and bzr is not doing anything wrong, especially as Vincent reports he can't reproduce it.
Releasing the read lock before acquiring the write lock as proposed in the original patch would be wrong. The contract of this locking code is that you can write-lock a file that was previously read locked.
Eventually, per bug 98836, we'd like to get rid of the use of os locks for dirstates and repositories, which will avoid the area that's causing trouble with this bug.