win32 selftest results

[John Arbash Meinel]

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

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)
> 
> 
> With plugins (with my win32symlinks plugin that provide fake symlinks
> support):
> 
> Ran 2819 tests in 1472.421s
> 
> FAILED (failures=17, errors=8)
> 
> As you can see something broken with symlinks support. Because this
> plugin is my child then I'll investigate it myself.
> 
> 
> 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.


> test_transport_implementations.TestTransportImplementation.test_unicode_paths(FakeNFSServer)
>              FAIL          46ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(FakeVFATServer)
>             FAIL          32ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(HttpServer_PyCurl)
>          FAIL          62ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(HttpServer_urllib)
>          FAIL          62ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(LocalRelpathServer)
>         FAIL          62ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(LocalAbspathServer)
>         FAIL          30ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(LocalURLServer)
>             FAIL          47ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(ReadonlyServer)
>             FAIL          31ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(SFTPAbsoluteServer)
>         FAIL          93ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(SFTPHomeDirServer)
>          FAIL          92ms
> test_transport_implementations.TestTransportImplementation.test_unicode_paths(SFTPSiblingAbsoluteServer)
>  FAIL         110ms

^-- All of these pass for me, though you could be right that it is an
issue about Encoding.

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


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

It sounds like something about your setup is translating filesystem paths.

> ...est_reconcile.TestsNeedingReweave.test_reweave_inventory_without_revision_and_ghost(RepositoryFormat7)ERROR
>         907ms
> ...st_reconcile.TestsNeedingReweave.test_reweave_inventory_without_revision_reconciler(RepositoryFormat7)ERROR
>         812ms
> 

^-- These were having problems with holding files open (Mostly
inventory.knit), but I got it working for me. If you read the logs and
see something like EPERM, that is what is going on.


> Unicode path tests fails probably because cp1251 <-> cp866
> inconsistency. I don't look into it yet, but I will.
> 
> test_contents_merge2 fails because diff3 on win32 change line-endigns
> and always return resulting file with CRLF line-endings.
> 
> Last two failing tests is most obscured for me.
> 
> -- 
> Alexander


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

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

iD8DBQFEp2zOJdeBCYSNAAMRAlaKAJ0W0uB4gnK6LJR4r5AJu98ruaNwwACeJt5w
N/es82rP3gAw8eJcDAI1Zu8=
=ugn8
-----END PGP SIGNATURE-----