Re: Tests fail on Windows

James Abbatiello wrote:
> I'm trying to run the latest trunk on Windows using Python 2.6.2 and
> there are some test failures.

That's not very surprising.  Thanks for testing under Windows and
submitting the patch!

> Tests 68-75 and 90 fail due to
> http://cvs2svn.tigris.org/issues/show_bug.cgi?id=124 .  Test 160 would
> also fail due to this but it is XFailed.  Are there any ideas how to
> address this?  It seems like it is going to become more of a problem
> now that Subversion 1.6 is out.

There are some not-very-satisfactory ideas listed in the bug report.

Probably the "correct" solution is for svntest not to parse the text
output of "svn log" at all but rather to use "svn log --xml" and parse
the XML output.  Presumably the Subversion project makes adequate
guarantees as to the backwards-compatibility of the XML output.
Probably this change should be implemented upstream.  But I haven't
pursued this.  The main questions are:

- Does the XML output contain all of the information needed by svntest?

- Is the XML output consistent across SVN versions (at least with
regards to the information needed by svntest)?

- Is there some reason that the Subversion project doesn't want to use
the XML output?

If you would like to look into this, that would be great.

> Besides that issue there are several
> other problems which are specific to Win32.  I've worked up a patch
> which is attached.
> 
> 1) Trying to call out to GNU sort always uses Windows sort even if GNU
> sort is available and appears in the PATH before Windows sort. [...]

Committed to trunk as r4820.

> 2) Symbol transforms aren't working.  In the the test for renaming
> multiply-defined symbols the constructor for SymbolMapper is passed
> Unix-style paths (see
> test-data/multiply-defined-symbol-cvsrepos/cvs2svn-rename.options).
> But the transform() method gets called with native paths.  I've tried
> to fix this by converting the paths to native when the SymbolMapper is
> constructed.  I've also made a similar change to SubtreeSymbolMapper
> which is untested.

Thanks, good catch.  It seems to me that it makes sense (on Windows) to
make the code work for either '/' or '\' and also to ignore the case of
the filenames.  So that is what I implemented (using os.path.normpath()
and os.path.normcase()) in trunk r4821.  Please let me know whether this
works for you.

> 3) The symbol_transform test creates a directory with a very long
> name.  Some files inside this directory eventually exceed the Windows
> limit of 256 characters in an absolute path which causes the test to
> fail.  I've tried to work around this by using a hash of the arguments
> in the directory name instead of using them literally.  This keeps the
> length down and preserves the existing guarantee that directory names
> won't have illegal characters in them.  The downside is that the
> directory names in the temp directory become somewhat harder to
> decipher.

I like the concept.  I was puzzled that you didn't include the
passbypass, options_file, and symbol_hints_file options in the hash but
rather kept them as parts of the filenames--doesn't this also make for
long filenames?

So I tried moving these options into the hash, too, but (as you
undoubtedly noticed) the options-file-based test cases have to know the
path to which the repository should be output, so it doesn't work.

So as trunk r4825 I committed something similar to your code, except
that it moves all of the parameters *except* --options into the hash.
It seems to work; let me know if it is OK for you.

> 4) The run-tests.py tries to set things up so that svn will output
> timestamps in UTC instead of using the local timezone.  The comment
> says "I have no idea if this works on Windows".  Well it doesn't work
> on Windows unfortunately.  Timestamps keep getting output in the local
> timezone.  There doesn't seem to be any way to override this behavior
> on Windows.  The timestamp_chaos test ends up failing with all the
> times off by a constant number of hours.  It doesn't seem too hard to
> handle timestamps in the local timezone and in fact the comments
> already make reference to doing this.  They don't seem to correctly
> describe what is going on now with svn configured to output UTC times.
>  A small change to interpret the times that are hardcoded in
> run-tests.py as UTC instead of local allows the test to run with svn
> outputting local timestamps.  As a bonus this makes the existing
> comments correct again.

Thanks.  Committed as trunk r4818.

By the way, if you submit more patches in the future, it would be
helpful if you would submit a separate patch for each logically-separate
change.

Thanks!
Michael

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2372444

To unsubscribe from this discussion, e-mail: [[email protected]].