[MERGE] Improve tests for the behaviour of Tree.iter_changes for missing paths that are only present in one tree, and fix found bugs. (Robert Collins)

John Arbash Meinel john at arbash-meinel.com
Wed Aug 13 15:17:10 BST 2008


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

Robert Collins wrote:
> On Wed, 2008-08-13 at 17:14 +1000, Andrew Bennetts wrote:
>> Robert Collins wrote:
>>> This makes the behaviour of missing files that are only in one tree
>>> consistent for all our InterTree implementations.
>> [...]
>>
>> bb:tweak
>>
>>> +    def test_only_in_source_and_missing(self):
>>> +        tree1 = self.make_branch_and_tree('tree1')
>>> +        tree2 = self.make_to_branch_and_tree('tree2')
>>> +        tree2.set_root_id(tree1.get_root_id())
>>> +        self.build_tree(['tree1/file'])
>>> +        tree1.add(['file'], ['file-id'])
>>> +        os.unlink('tree1/file')
>>> +        tree1, tree2 = self.mutable_trees_to_locked_test_trees(tree1, tree2)
>>> +        root_id = tree1.path2id('')
>>> +        if not tree1.path2id('file'):
>>> +            # The locked test trees conversion could not preserve the missing
>>> +            # file status. This is normal (e.g. InterDirstateTree falls back
>>> +            # to InterTree if the basis is not a DirstateRevisionTree, and
>>> +            # revision trees cannot have missing files. 
>>> +            return
>> Hmm, wouldn't raising TestNotApplicable be more appropriate than just returning?
> 
> TestNotApplicable, because its an exception, shows up as an error or
> failure in a downlevel test runner. That doesn't match what is going on
> here. (Or to put it another way, I don't like TestNotApplicable all that
> much, because 'raise' and 'not a problem' just don't fit in my head).
> 
> -Rob

I really prefer it in *our* test runner, and it *is* our convention.

As our test suite doesn't really run in other runners anyway...

I'm concerned that some WT might eventually decide that path2id() should
return None for files that aren't present on disk, I don't know if it is
explicitly tested or not.

Otherwise BB:approve.

John
=:->

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

iEYEARECAAYFAkii7OYACgkQJdeBCYSNAAPQJACgq+8z1mXc5RrvJvRzEZftwk/G
MVwAn1e/pEmSC9rki5HnjD/akEmGrxBI
=3Zjl
-----END PGP SIGNATURE-----



More information about the bazaar mailing list