[RFC] Fixing bug #306394: status should tolerate nonexistent file.

[Martin Pool]

On 17 Dec 2008, Karl Fogel <karl.fogel at canonical.com> wrote:
> I'm working on bug #306394 ("bzr status should not ignore all other
> command line arguments when passed a non-existent file").
> 
> The basic fix is here (review welcome!):
> 
>    http://bazaar.launchpad.net/~kfogel/bzr/306394-status-tolerate-nonexistent/revision/3910

Thanks for that.

It's strange that you're importing just the 'warnings' module but then
calling the unqualified function 'warning'; that suggests either it was
already imported or your tests didn't hit this line. :-)

The Python warnings module is for programmer warnings; for things like
this I think you should just write to stdout in the same manner as the
rest of status.  Writing the warnings to stderr may make it
unsynchronized with stdout (due to separate buffering) and may make it
harder for programs like emacs to parse it.

> test_status_nonexistent_file(), which looks for the current behavior:
> 
>     def test_status_nonexistent_file(self):
>         # files that don't exist in either the basis tree or working tree
>         # should give an error
>         wt = self.make_branch_and_tree('.')
>         out, err = self.run_bzr('status does-not-exist', retcode=3)
>         self.assertContainsRe(err, r'do not exist.*does-not-exist')
> 
> Does that test mean that the current behavior is desirable for some
> reason, and should not be considered a bug?  Otherwise, I'll simply
> adjust this test to expect a non-fatal warning instead of an error.
> 
> Or if the current behavior (fatal error) is desirable, then we should
> probably close the bug as invalid.

I think the current behaviour was the intended behaviour when this was
written, but we've now realized it's not the best.

You should expect a message about it, probably in stdout.  If you can
match the whole line or the whole output that would be more precise than
just looking for the filename.

(Incidentally I just filed <https://bugs.launchpad.net/malone/+bug/311060> 
about the way Launchpad loses the address details in mail sent both to a
bug and to the list.)

Thanks for working on this.

-- 
Martin      <http://launchpad.net/~mbp>