win32 selftest results

[Alexander Belchenko]

John Arbash Meinel пишет:
> Alexander Belchenko wrote:
>> John Arbash Meinel пишет:
>>> So after this fix, the test suite should pass on win32. Is it passing
>>> for you Alexander?
>> I pull your branch up to revno.1821.
>>
>> And there is failing tests.
>>
>> Without plugins:
>>
>> Ran 2790 tests in 1335.062s
>>
>> FAILED (failures=13, errors=6)
>>
>> But in standard (w/o plugins) case here is list of failed tests:
>>
>> test_transport_implementations.TestTransportImplementation.test_copy(FtpServer)
>>                          ERROR         219ms
>> test_transport_implementations.TestTransportImplementation.test_copy_to(FtpServer)
>>                       ERROR         266ms
>> test_transport_implementations.TestTransportImplementation.test_move(FtpServer)
>>                          ERROR          94ms
>> test_transport_implementations.TestTransportImplementation.test_put(FtpServer)
>>                           ERROR         108ms
> 
> 
> You're right, I'm not running the FTP server tests. I don't think we
> really can support a generic MS FTP server. I think we will support
> pushing from Windows onto someone else's ftp server, though. And that is
> what other platforms will test.
> I might investigate this in the future, but most likely it means fixing
> up the FTP server itself, more than actually fixing up the tests.
> Either that, or we need to introduce fancy_rename() for the
> FtpTransport.put() like we do for SftpTransport.

I remember that in last month there was bug report in the mailing list 
from person who cannot push to win32-based ftp server because of rename 
error. So I think is better solution is fancy_rename() for ftp.

>> test_merge_core.MergeTest.test_contents_merge2
>>                                   FAIL        2765ms
> 
> ^-- This used to fail for a different reason. My version of diff3 came
> from cygwin, and I have the binary flag set, so it doesn't translate
> line endings.
> I can't say much other than we could skip the test. The dependency we
> are using is not providing us with correct support.

I'm also think it should be skipped.

>> test_nonascii.UnicodeFilename.test_platform
>>                                   FAIL          30ms
> 
> ^-- I'm very suspicious about your setup if this test is failing, and it
> make explain while all the other Unicode tests are failing.
> This test just checks that if I create 3 files with unicode filenames,
> when I do a 'os.listdir(u'.')' I get those three names back.
> And then on Mac it checks that the filenames have been normalized.
> 
> Can you send me the log for test_nonascii.UnicodeFilename.test_platform
> That one may be the most revealing. (I'm busy the rest of the weekend,
> but I'll try to look into it on Monday).

This log is shortest one:

======================================================================
FAIL: test_platform (bzrlib.tests.test_nonascii.UnicodeFilename)

vvvv[log from 
bzrlib.tests.test_nonascii.UnicodeFilename.test_platform]-------
converting os path '.' => url 
file:///E:/work/MyCode/bzr/devel/jam.win32/test0000.tmp/test_nonascii.UnicodeFilename.test_platform

^^^^[log from 
bzrlib.tests.test_nonascii.UnicodeFilename.test_platform]-------
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"E:\work\MyCode\bzr\devel\jam.win32\bzrlib\tests\test_nonascii.py", line 
75, in test_platform
     self.assertEqual(expected, present)
AssertionError: [u'\xe4', u'\xe5', u'\u017d'] != [u'\xe4', u'\u017d']

----------------------------------------------------------------------

I think can be that u'\xe5' != u'\u00e5'?

--
Alexander