[MERGE] Fix for 306394: warning, not error, on non-existent file.

[Ian Clatworthy]

Aaron Bentley wrote:
> Karl Fogel wrote:
>> Aaron Bentley <aaron at aaronbentley.com> writes:
>>>>> Why is it bad to error on a non-existent file?  What are the use cases?

> But from my POV, that's not what status is for.  It's for asking about
> files that are versioned, or might be versioned.  Asking about files
> that don't exist suggests a deeper error, so it makes sense to me to
> stop.  It also keeps the exit codes simple.
> 
> I expect there are two common usages for "status":
> - "bzr status"
> - "bzr status $FILE"
> 
> For "bzr status $FILE", it might as well be an error.  It's only when
> you're listing multiple files that it really makes a difference.  And
> listing multiple files at the commandline is usually not worth the effort.

There's another (pending) example where reporting non-existence will
be better than generating an error: filtered views. If a user creates
a view, then the list of files in that view is effectively implicitly
given to commands like status and commit. Removing one of those files
shouldn't stop status from reporting about the rest. (Furthermore, it
would be wrong to immediately remove the file from the view when it
is 'bzr remove'd - the removal needs to be committed first.)

>> For
>> some of those names, the status is "does not exist".  Fine -- let's
>> report that, and report the status of the other paths as well, rather
>> than treat non-existence as so special that it must suppress other
>> statuses from being reported.
> 
> If you really want to treat non-existence as a status, it does not make
> sense to emit a warning.  Warnings go to stderr, while normal status
> output goes to stdout.  Using a warning would mean that you cannot
> capture the full status by redirecting stdout.  But if you're going to
> emit to stdout, the output should conform to our existing output styles.

Agreed.

Ian C.