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

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> 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.

I would just like to mention that we already handle:

$ bzr init
$ touch present removed unknown
$ bzr add present removed
$ bzr commit -m first
$ rm removed

$ bzr st present removed unknown
removed:
  removed
unknown:
  unknown
$ bzr st --short present removed unknown
 D removed
?  unknown

However with a non-existent and not versioned file you get:
$ bzr st prsent removed unknown missing
bzr: ERROR: Path(s) do not exist: missing

I could see putting not-present files into the 'unknown' category. So doing:

$ bzr st --short present removed unknown missing
 D removed
?  unknown
?  missing

Or we could put them in a "not present:" category. Or if we want a
single word "nonexistant".

Honestly, I don't see why emacs is asking the system for the status of a
file that doesn't even exist and never has existed (from bzr's view).
Something seems seriously broken in "vc-dir". I don't know where it is
coming up with these "nonexistant" files to be asking bzr about.

I won't doubt that it happens, but I don't quite understand why it isn't
a bug in emacs and 'vc-dir' (which would mean nothing would change in
bzr). Now, if it is just customary to ask about a file that is *about*
to be created, I suppose that is understandable.

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

If we are going to change it, then I would say that we sohuld just come
up with a way to represent them in both short and long forms.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklRktkACgkQJdeBCYSNAANxWgCgpAw4vXss7Q0Y2WhzJqpiJcZF
tuUAn0+w+yg/yTK3UYcyRcqyOtPvW0Kz
=o3LW
-----END PGP SIGNATURE-----