Comment 3 for bug 141172

I believe the first portion is that we didn't want to kill the ssh subprocess instantly, so that we have time to recover from errors, rather than just getting EOF or broken pipe from the connection.

But I agree that we should eventually get the process to close down and exit.

Even more, though, I think that if bzr+ssh is waiting on a lock on the server end, even if the client is killed, it won't detect that until it can actually grab the lock and then tries to talk to the client. Which causes some odd double-locking issues (I think that is a different bug, though.)