[MERGE] Hidden bug in `bzr info` when dirstate tree is write-locked

[John Arbash Meinel]

Martin Pool wrote:
> On 4/24/07, John Arbash Meinel <john at arbash-meinel.com> wrote:
>> We could, but for now I'm just checking earlier that "bzr info" is
>> failing.
>>
>> Right now you can see that I do:
>> +        if tree_locked and sys.platform == 'win32':
>> +            # Arguably neither can Linux, but for now OS Locks are
>> +            # not exclusive in-process.
>> +            args = command_string.split(' ')
>> +            self.run_bzr_error([], 'info', *args)
>> +            return
>>
>>
>> Which means that if it starts *working*, the test will start failing,
>> which is a clue that it needs to be updated. I realize it isn't
>> completely obvious, because the place checking for the actual failure is
>> decoupled from the place that is raising "knownFailure".
> 
> As I said on irc, I found it a bit unobvious.  I think you need to at
> least explain why you're doing this.  Personally I think it would be
> ok for this test to just say knownFailure and not actually test it.
> +1 to do the knownFailure for 0.16
> 

Well, I updated the comment as we discussed on IRC.

I personally feel that you should never raise "knownFailure()" without
actually checking that it fails.

If only because if the underlying failure is ever fixed, you have no
idea what tests need to be updated (because they are all "passing").

I suppose you could set a flag that makes "knownFailure" actually mark
the test as failed. But if we start using "knownFailure" for more things
(and there seems to be a trend in that direction) you will end up with
100 failing tests at that point. Which again makes it unclear what you
should actually be updating.

John
=:->