| 2007-06-26 15:42:00 |
John A Meinel |
bzr: statusexplanation |
|
I'm not sure if this is a bug in bzr, or a bug in bzr-gtk, or if it is actually a "design feature".
Specifically, the problem is that bzr-gtk is locking the tree in read-only mode. Which sort of indicates (to me) that you shouldn't be able to write to it (since it is readonly).
In the past, our read-locks were no-ops because our data structuring generally meant that a writer could not invalidate a reader. But the way we write dirstate now means there is a potential race condition (I'm reading while you are writing), so we use a read lock.
A few possible solutions:
a) Does 'bzr gannotate' need to keep a read-lock on the WT? It could probably grab one when it starts annotating, and then release it once it has the display running.
b) Does 'bzr viz' need a WT lock at all. I could understand it having a Branch lock, but those *are* no-op read-locks.
c) Is it just that this error is not as clear as it could be? "Resource Temporarily Unavailable" versus "Could not lock tree for writing" or "Tree is locked readonly" or something else.
I'll include bzr-gtk as part of this bug, and we can sort out what we want to do about it.
Note, that this also happens for "bzr diff | less" if it is long enough to block the pipe, and then "bzr commit". Or especially "bzr commit" popping up the message editor, and running "bzr diff" in another window.
The fact that we pun read-lock with the length of time to cache information in memory might also be evaluated. But honestly, it is only *safe* to cache if you have a lock, so that you know things aren't changing.
We've also discussed changing things again so that we can avoid OS locks entirely. They seem nice in a lot of ways, (they clean up after themselves, etc), but if we avoid them we structure code closer to not having locks at all (no-op read locks) which has its own benefits. |
|
