[MERGE][BUG #177809] bzr SOURCE DESTINATION tweaks

[Spencer Chastain]

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

On Wed, Feb 27, 2008 at 2:19 PM, Alexander Belchenko <bialix at ukr.net> wrote:

> 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.
>
> For details, see:
>
> http://bundlebuggy.aaronbentley.com/request/%3C64ab70ac0802041811u61752e66l3a04f025336390ae%40mail.gmail.com%3E
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20080301/28d537f2/attachment.htm