> or prompted me "Do you want to break this lock?"
I think we probably don't want to do this, because making a usually non-interactive command just occasionally interactive is likely to frustrate people writing scripts, cron jobs, etc.
> 2. If bzr break-lock had given me some feedback when run without arguments
> (e.g. "Breaking lock on local directory" or "No lock on current directory"). Note that -v
> doesn't print any information out.
This seems like a good idea. We should probably make it verbose as you suggest by default, and let people use -q if they really don't want to see output.
> (I was also confused by the "Will continue to try until 23:50:32, unless you press Ctrl-C."
> line - push was not blocking at that time).
That's also odd. I'm not sure why that would be the case off the top of my head, possibly something odd in the way the server process sets lock timeouts to 0? First thing to figure out here is if that message is being emitted by the client, or passed along from the server's stderr.
> 1. If bzr push had given me the complete command-line to break the lock
That is bug 250451.
> or prompted me "Do you want to break this lock?"
I think we probably don't want to do this, because making a usually non-interactive command just occasionally interactive is likely to frustrate people writing scripts, cron jobs, etc.
> 2. If bzr break-lock had given me some feedback when run without arguments
> (e.g. "Breaking lock on local directory" or "No lock on current directory"). Note that -v
> doesn't print any information out.
This seems like a good idea. We should probably make it verbose as you suggest by default, and let people use -q if they really don't want to see output.
> (I was also confused by the "Will continue to try until 23:50:32, unless you press Ctrl-C."
> line - push was not blocking at that time).
That's also odd. I'm not sure why that would be the case off the top of my head, possibly something odd in the way the server process sets lock timeouts to 0? First thing to figure out here is if that message is being emitted by the client, or passed along from the server's stderr.