[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Win32 test failures

From: D.J. Heap <dj_at_shadyvale.net>
Date: 2005-07-01 19:09:40 CEST

kfogel@collab.net wrote:
> I think the relevant code is in svntest/wc.py:State.write_to_disk(),
> this line:
> open(fullpath, 'w').write(item.contents)
> Should that be 'wb', to ensure that we write exactly what we say in
> svntest/main.py:greek_state?

Yes, according to the python docs that is correct. And that change fixes it
although it then breaks a stat test -- this patch fixes them both:

Index: subversion/tests/clients/cmdline/stat_tests.py
--- subversion/tests/clients/cmdline/stat_tests.py (revision 15216)
+++ subversion/tests/clients/cmdline/stat_tests.py (working copy)
@@ -603,7 +603,7 @@
    "text-time behaviour"

    # Pristine text and text-time
- fp = open(wc_path, 'r')
+ fp = open(wc_path, 'rb')
    pre_text = fp.readlines()
    pre_text_time = get_text_timestamp(wc_path)

@@ -616,7 +616,7 @@
      raise svntest.Failure

    # Manually reverting the text does not affect the text-time
- fp = open(wc_path, 'w')
+ fp = open(wc_path, 'wb')
    expected_status.tweak(status_path, status=' ')
Index: subversion/tests/clients/cmdline/svntest/wc.py
--- subversion/tests/clients/cmdline/svntest/wc.py (revision 15216)
+++ subversion/tests/clients/cmdline/svntest/wc.py (working copy)
@@ -102,7 +102,7 @@

          # write out the file contents now
- open(fullpath, 'w').write(item.contents)
+ open(fullpath, 'wb').write(item.contents)

    def old_tree(self):
      "Return an old-style tree (for compatibility purposes)."

There is also a file_append function in main.py that opens files in text
mode -- but changing it to binary mode caused several tests to start
failing. I'm not sure if it should be changed and the tests fixed, or what

>>FAIL: diff_tests.py 14: diff text-bases against repository
> In the headers, it uses forward slashes. I guess that makes sense;
> that's what 'patch' expects, after all. But this means that in the
> nested function in diff_tests.py:diff_base_to_repos()
> def convert_lines(lines):
> return [x.replace("/", os.path.sep).replace("\n", os.linesep)
> for x in lines]
> ...at least the first replacement is wrong. (Mea culpa. I can fix
> that pretty easily, anyway.)
> However, the weirder thing is that the diff consistently has CRLF on
> the ends of the header lines, but LF on the ends of the diff hunk
> portions, *no matter whether svn:eol-style is set to native or not*.
> Obviously, I can rewrite the test to expect its output in a cleverer
> way. For example, just chop off both CRLF and LF from the ends of
> lines, in both the expected and actual output, and then do the
> line-by-line comparison. I guess I'll do that.

Your change made the diff tests pass for me.

I think diffs have been created like this on Windows as long as I can
remember -- I guess I just assumed that for patches to be as cross platform
as possible, the line endings had to be LF. Would patch handle a CRLF hunk
from a Windows box sent to a Linux box (without any newline translation) on
a eol-style native file correctly? Is that an important use case?

It would be nice to fix the header inconsistency for sure, though. I think
that inconsistency causes some versions of patch to croak.

>>FAIL: blame_tests.py 4: blame output in XML format
> This one puzzles me, because I'm basically doing the same thing the
> old test did, just with a bigger output chunk. Presumably if it still
> works on Unix (which it does), it should still work on Windows.
> Obviously I'm missing something.

I think the blame test failure is related to it's use of file_append which
opens the file in text mode...I'm not sure, though, and I'm out of time at
the moment. I'll have to look at it next week if needed.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 1 19:31:37 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.