As of bzr 1.12 (and many previous versions) the dirstate working tree format uses an OS lock on the dirstate file. This was done so that we could safely make in-place updates to the dirstate file. Bzr also (and its tied to the OS lock usage) uses an edit-inplace approach to modifying the file.
However, this causes several problems:
* While the dirstate file is locked, it cannot be read: eg by info (bug 174055) or by diff
* OS locks don't work well on all platforms
* They are particularly problematic on network filesystems, which often don't have working file locking either inherently or because of a configuration problem, eg smb (bug 31006), AFP (bug 114528), nfs (bug 108605)
* OS lock behaviour varies between platforms therefore is harder to test and debug, eg bug 305006
* On some platforms, OS locks are implicitly shared across a process and this makes them harder to test and/or hides bugs
* OS locks can't be broken and don't show who is holding the lock
* OS locks are not supported by Jython
* When the disk is full or bzr crashes the dirstate file can be shorter than it should be.
All these bugs are collected into this one bug, as few of them can be fixed without fixing the OS lock issue, and fixing the OS lock issue will fix them all.
If the use of diff and stat while a commit editor is open is fixed in a different way - e.g. by a separate stat cache, then we can just modify this description to only list the remaining issues.
These bugs are somewhat distinct aspects so shouldn't be marked as dupes, but they can probably best be fixed together.
Totally fixing this requires changing the format not to rely on file locking, which requires a format that is safe if it is being read and written simultaneously. That format can't assume any particular behaviour if an attempt is made to rename a file while it's being read, because that can either fail, cause an error for the reader, or follow the rename, depending on the platform.
Some partial fixes may also be possible.