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

[Stephen J. Turnbull]

Aaron Bentley writes:

 > I don't know why this GUI assumes that it can request the status of
 > non-existent files.

Perhaps because existence is a time-dependent thing?  Because humans
sometimes do things behind the VCS's (or editor's) back?

 > It could presumably request a full status of the tree instead,
 > which would be more efficient than asking about invividual files.

vc.el deals with many different VCSes, and asking about the whole
tree might or might not be more efficient.  In particular, it might
provide excessively verbose output which then would have to have the
relevant bits parsed out.  In any case, that's not what it does
... since, oh, 1992 or so.

 > But from my POV, that's not what status is for.  It's for asking about
 > files that are versioned, or might be versioned.

What makes you assume that the (at this instant) non-existent file
wasn't versioned in the past, or isn't scheduled for versioning in the
future?  Isn't it possible that vc.el, which (in this scenario) has a
much more intimate relationship to the user, knows far more about
the user's plans than bzr does?

 > I expect there are two common usages for "status":
 > - "bzr status"
 > - "bzr status $FILE"

Why are you surprised that surprising things happen?<wink>  When bzr
is being driven by a program, what is common usage is determined by
the vagaries of the implementation, not by what humans might (or might
not) reasonably expect.

 > 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 no effort involved here because vc.el is doing the work.

In any case, I disagree with your assessment; "$VCS status *.$EXT" is
a common idiom for me.

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

ehem ... if your quote is any fair representation of KarlFogelThought,
that is exactly what he is suggesting.