Comment 1 for bug 172392

I'm guessing the fix might be for the bzr serve process to notice when the client has exited after taking the lock, and go ahead and unlock itself.
I know we are trying hard for the smart protocol to be stateless, though. Which makes it difficult to have any sort of chat between the client and server, to let it know that the client is still around.

Another issue is having the bzr server say to the client "I'm waiting on the lock, I'll get back to you in a bit." I'm not sure this can be done if we expect each RPC to have a single Request => Response. Rather than a Request => Ongoing Response. Though if HTTP supports "Ongoing Response" then we could probably make use of it.

The *best* solution is to get more smarts in the protocol, so that we never actually have to request a lock be taken. If all actions are streamed and self-contained then the bzr process on the server will lock and unlock on its own, and not care if the client disconnects.