The main problem with the UI, particularly as it relates to the mv command, is that it is not clear to the user what has and  what has not happened.  Commands either succeed or they don't.  In the situations that they don't succeed, they typically (that is to say, in my experience) fail in one of two ways: 1.  When the command exits, nothing has changed from before the command was issued 2.  The command continues to execute and reports errors as they occur - while also reporting successes as they occur under normal successful operation. bzr mv really doesn't operate like any of that, particularly as it relates to failure.  In the case that it succeeds, the successes are cached and then printed just prior to end of execution.  But if it fails, it just fails with an error message - no indication that there is any successes and no information about the state of everything else.  This lack of indication/information is particularly dissonant to the bzr mv command because under normal operation, successes are reported - so users are inclined to think that if there is information to report beyond just failure, bzr would report it.  I modified bzr mv to behave as a  modified second failure option because I prefer formatted and organized output over random success and failure messages.  I know that as unix users we're use to the kind of reporting you get with a recursive grep or find or ls (i.e. reports on successes, reports on failures, as they happen) - but while I'm use to it, I still find it incredibly annoying.  Aside from knowing that it's working, I don't really care to know about the status of each and every file until the end - and then I want it organized because all I really care about is failure. Either way, I don't think it's a good idea for failures to end the command - and certainly not without full reporting of successes and failures (and, I suppose also, non-attempts). So, I see at present three options for improving the UI for this command: 1. Report successes as they occur, end execution at first failure, and in the event of failure, report both failure and non-attempts 2. Report successes as they occur, report failures as they occur, and do not end execution upon failure 3. Cache successes and failures until the end of execution and then report all attempts, grouped according to success and failure 4. A last option to consider is to mirror more closely the standard mv command.  Messing with unix mv, I see: $ touch a $ touch d $ mkdir dir $ mv a b c d dir mv: cannot stat `b': No such file or directory mv: cannot stat `c': No such file or directory $ ls dir a    d So in emulating more closely unix mv behavior, we could turn off success reporting for bzr mv, attempt to move all files in the argument list, and only report errors of those that fail. Are there other options that should be considered?  If not, then what option would the bzr team prefer. --Spencer <div class="gmail_quote">On Wed, Feb 27, 2008 at 2:19 PM, Alexander Belchenko <<a href="mailto:bialix@ukr.net">bialix@ukr.net</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Alexander Belchenko has voted comment. Status is now: Waiting Comment: Your approach is not comfortable for me. I'd like to either fix original bug by printing information about each rename immediately, so user will see what done and where command failed. I think your patch needs more discussion about intended UI for this use case. <div><div></div><div class="Wj3C7c"> For details, see: <a href="http://bundlebuggy.aaronbentley.com/request/%3C64ab70ac0802041811u61752e66l3a04f025336390ae%40mail.gmail.com%3E" target="_blank">http://bundlebuggy.aaronbentley.com/request/%3C64ab70ac0802041811u61752e66l3a04f025336390ae%40mail.gmail.com%3E</a> </div></div></blockquote></div>