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

[Aaron Bentley]

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?
>>> From the bug's description:
>> I read the bug's description, both now and when it was originally filed.
>>  It didn't convince me or motivate me to address it.  I'm asking you,
>> because it did convince and motivate you.
> 
> I can't quite tell if you're asserting that the original behavior is
> better, or just wondering why I bothered to fix such a minor bug :-).

I wasn't convinced that it was a bug.  I think it makes sense for it to
behave as it does.

> If the latter: 
> 
> Because it's one of the 4 blockers keeping the GNU Emacs project from
> switching to bzr (look for bugs tagged with "emacs-adoption" to see them
> all).  Specifically, the line in the bug description about:
> 
>    "This type of operation occurs in normal usage in emacs when using
>     the vc-dir GUI."

I don't know why this GUI assumes that it can request the status of
non-existent files.  It could presumably request a full status of the
tree instead, which would be more efficient than asking about invividual
files.  So I don't understand why this is a blocker.  There doesn't seem
to be any deep technical issue.

> Independently of Emacs, I think warning is a better behavior here than
> erroring.  The user has asked for status on a number of path names.

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.

We usually treat non-existent files as an error, so this change adds
inconsistency.

> 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.

Aaron