"D.J. Heap" <dj@shadyvale.net> writes:
> dj@shadyvale.net wrote:
> > Running all tests in svnversion_tests.py...success
> > Running all tests in utf8_tests.py...success
> > Running all tests in history_tests.py...success
> > Running all tests in lock_tests.py...success
> > Running all tests in cat_tests.py...success
> > Running all tests in import_tests.py...success
> > At least one test FAILED, checking M:\tests-local\tests.log
> > FAIL: copy_tests.py 19: repos->WC copy with keyword or eol property set
> > FAIL: diff_tests.py 14: diff text-bases against repository
> > FAIL: blame_tests.py 4: blame output in XML format
> > At least one test was SKIPPED, checking M:\tests-local\tests.log
> > SKIP: ra-local-test.exe 4: svn_ra_local__split_URL: invalid host names
> > SKIP: commit_tests.py 32: tabs in paths
> [snip]
>
> I'm getting these 3 new test failures since the test changes in
> r15191. I've attached the log output.
>
> I won't have a chance to investigate these until next week, probably.
Okay, I've looked into these, and like not what I see.
> FAIL: copy_tests.py 19: repos->WC copy with keyword or eol property set
One of the first things this test does is propset svn:eol-style on
iota:
svntest.actions.run_and_verify_svn(None, None, [],
'propset', 'svn:eol-style',
'CRLF', iota_wc_path)
The test is failing because that propset results in error:
svn: File 'svn-test-work\working_copies\copy_tests-19\iota' has \
inconsistent newlines
svn: Inconsistent line ending style
But why? Right before the propset, iota should have these contents:
This is the file 'iota'.\n
Hello\n
Subversion\n
$LastChangedRevision$\n
I've written in the newlines, to make it clear that they should be
literal LF characters. The first line is simply the default contents
of the file (post-r15191). The next three lines result from this prep
work in the test:
f.write("Hello\nSubversion\n$LastChangedRevision$\n")
So, one possibility is that when we create the default greek tree
working copy, we're writing the files out in text mode, and so even
though svntest/main.py:greek_state is initialized with LF line
endings, the working copies get CRLF on Windows. That would mean iota
would look like this
This is the file 'iota'.\r\n
Hello\n
Subversion\n
$LastChangedRevision$\n
right before the propset.
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?
> FAIL: diff_tests.py 14: diff text-bases against repository
I have sort-of-kind-of access to a Windows machine, so I looked at how
'svn diff' behaves on Windows. Unless I misinterpreted the output,
the answer ain't pretty. Watch this:
C:\WINDOWS\temp\kff\subversion-trunk\notes>svn --version
... 1.2.0 ...
C:\WINDOWS\temp\kff\subversion-trunk\notes>svn plist -v skip-deltas
C:\WINDOWS\temp\kff\subversion-trunk\notes>svn plist -v svndiff
Properties on 'svndiff':
svn:eol-style : native
C:\WINDOWS\temp\kff\subversion-trunk\notes>notepad skip-deltas
[... make trivial edits to a couple of lines, save ...]
C:\WINDOWS\temp\kff\subversion-trunk\notes> notepad svndiff
[... make trivial edits to a couple of lines, save ...]
C:\WINDOWS\temp\kff\subversion-trunk\notes>cd ..
C:\WINDOWS\temp\kff\subversion-trunk>svn diff notes
Index: notes/skip-deltas^M
===================================================================^M
--- notes/skip-deltas (revision 15200)^M
+++ notes/skip-deltas (working copy)^M
@@ -59,7 +59,7 @@^M
In the BDB back end, each revision of a file is represented as a delta
against a newer revision of the file--the opposite of FSFS. The
newest version of a file is stored in plain text. Whereas in FSFS, we
-add a new version of a file simply by picking a delta base and writing
+add a new version of a file simply by xpicking a delta base and writing
out a delta, in BDB the process is more complicated: we write out the
new version of the file in plain text; then, after the commit is
confirmed, we go back and "redeltify" one or more older versions of
Index: notes/svndiff^M
===================================================================^M
--- notes/svndiff (revision 15200)^M
+++ notes/svndiff (working copy)^M
@@ -17,8 +17,8 @@^M
window.
An svndiff document begins with four bytes, "SVN" followed by a zero
-byte which represents a version number. After the header come one or
-more windows, until the document ends. (So the decoder must have
+byte xwhich represents a version number. After the header come one or
+more xwindows, until the document ends. (So the decoder must have
external context indicating when there is no more svndiff data.)
A window is the concatenation of the following:
C:\WINDOWS\temp\kff\subversion-trunk>
(In that quoted diff output, I have replaced literal CR characters
with "^M", just to avoid mailers munging it.)
Some interesting things about that diff output:
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.
But the more important question is, is there a bug in 'svn diff'
output on Windows? The inconsistent line endings seem wrong, and
maybe the ignoring of svn:eol-style is wrong too. I don't know
whether there's a good reason for things to be this way. Any Windows
experts care to comment?
> 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 I've fixed the diff_tests.py problem in r15201. My Windows
development environment (and skill) is exceptionally poor, though.
Would you mind investigating the copy_tests.py and blame_tests.py
failures?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 30 20:56:42 2005