[merge] win32- more test suite fixes
Aaron Bentley
aaron.bentley at utoronto.ca
Fri Jun 30 18:31:50 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Arbash Meinel wrote:
> Aaron Bentley wrote:
> I suppose we could wrap the 'fancy_rename()' in a try/catch and do:
>
> try:
> fancy_rename(...)
> except OSError, e:
> if e.errno == errno.EPERM:
> os.lstat(old)
> raise
>
> That should translate an EPERM into a ENOENT when appropriate, without
> the extra overhead.
That's what I had in mind, but if you'd rather do it the simpler way, okay.
>>>What bugs me is that if we enter the finally block due to an exception,
>>>and then self.tt.finalize throws, we'll never see the original
>>>exception. I'm fine with doing it in this case, but we should find a
>>>more general solution.
> Well, I can restore what you originally had.
No, your change is definitely an improvement.
> Or I could just restore it to the old code. I removed it to track down a
> different bug, which is now fixed, so I don't *need* to see the tt
> exceptions.
No, as I said, I'm fine with doing it in this case. Generally, though,
I think we should look at having an Exception class that bundles
multiple exceptions together.
>>>I don't understand what the following changes are all about:
>>>
>>>@@ -67,6 +71,7 @@
>>> # J changes: 'b-file-id-2006-01-01-defg'
>>> # K changes: 'c-funky<file-id> quiji%bo'
>>>
>>>+ self.branch = None
>>> main_wt = self.make_branch_and_tree('main')
>>> main_branch = main_wt.branch
>>> self.build_tree(["main/a","main/b","main/c"])
>
>
> ^- this is done to handle passing/skipping the test.
>
>
>>>set(self.branch.repository.get_ancestry(new)).difference(set(self.branch.repository.get_ancestry(old)))
>>>
>>>- self.assertEqual(
>>>+ self.assertDictsEqual(
>>> {'b-file-id-2006-01-01-defg':set(['rev-J']),
>>> 'c-funky<file-id> quiji%bo':set(['rev-K'])
>>> },
>
>
> The old code was calling assertEqual() with two dictionaries. I thought
> that wasn't allowed, since order isn't preserved, but I just realizeh it
> probably only isn't allowed if you are just looking at the keys.
> I can revert this.
It just didn't seem to be explained anywhere, and there was a lot of it.
I wasn't sure whether it meant that dictionaries behaved differently
under Windows. It seems positive in general, so keep it.
>>>Shouldn't this be a TestSkipped?
>
>
> There were other comments in the code that said:
> # this is not a skip because newer formats do support this,
> # and nothin can done to correct this test - its not a bug.
>
> I know Robert has the feeling that TestSkipped is meant for things that
> can be fixed and run eventually. Not just for things that are known
> broken and we aren't fixing (testing old formats)
My feeling is that a test shouldn't pass unless it was run to completion
successfully. E.g. a test that cannot be performed on Windows may still
be a failing test, and should be run on another platform to ensure that
it passes.
I can think of three alternatives to pass/fail.
1. expected failure
2. cannot be performed on this platform
3. requirements not satisfied
1 can be considered a 'pass', in a sense. It doesn't do what we want,
but it does what we're expecting. At least it didn't fail for a
different reason!
2 means 'please rerun me on another platform'
3 means 'please install (paramiko|pycurl|...)'
> If self.branch is None, that means we couldn't setup the test. Primarily
> because we are on Win32, and one of the files is using <> in the
> file_id, which we didn't escape before knits.
Oh, right.
> This is known broken, and we aren't planning to fix it, we have newer
> stuff that does it correctly. If we are okay with TestSkipped, I can
> raise that inside setUp() and make my life easier. In setUp() I already
> know I need to exit, but calling return doesn't do anything, you have to
> 'return' from the actual test function.
>>>How about this:
>>>
>>> f = open(self._limbo_name(trans_id), 'wb')
>>> try:
>>> try:
>>> unique_add(self._new_contents, trans_id, 'file')
>>> for segment in contents:
>>> f.write(segment)
>>> finally:
>>> f.close()
>>> except:
>>> os.unlink(self._limbo_name(trans_id))
>>> raise
>>>
>>> f.close()
> Your final 'f.close()' will never get called. You raise before you reach
> it. Though I think it was just a typo.
It was.
> Also, with your proposal, we will
> double-cleanup in the case that segment in contents raises.
Drat. Yeah, you got me.
> I think I prefer this, as double closing a file is never an error, and
> it does the right thing:
> But what about turning it around, and not creating the file if we can't
> add a new contents:
> I realize this opens up the other problem, where we now have a
> _new_contents entry, but no file.
Right, that's why I didn't want to do it that way.
> So I would probably go with the first
> one, it is the most correct, and the ugliest :(
TreeTransform tends that way anyhow. Ugly, but right.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEpWAG0F+nu1YWqI0RAqwvAJsGzcjcjKvG8aKk6ML7h9xYZaj9twCfQBIS
FyRT50rbp5SkuW7R8dvHfTE=
=XLhp
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list