[svk-devel] test t/06keyword.t fails

[Dave Howorth]

Dr Bean wrote:
> Dave Howorth wrote:
>>>I'm trying to install SVK-1.08 from CPAN but it's failing:
> 
> I have the same problem on Fedora Core, but the same test failed
> for me installing earlier versions.

At least I'm not going mad then :)  What I don't understand is why more 
people aren't reporting the problem.

> I went ahead and installed by hand, perl Makefile.PL && make &&
> make install.

I'm reluctant to do that because I don't know what may come back to bite 
me at some point when I've forgotten all about the issue :(

>>I've done some more investigation:
> 
>>>t/06keyword..................ok 20/27
>>>#   Failed test in t/06keyword.t at line 99.
>>>t/06keyword..................NOK 21#          got: 'native
>>># '
>>>#     expected: 'native
>>># '
>>>t/06keyword..................ok 24/27Use of uninitialized value in 
>>><HANDLE> at /root/.cpan/build/SVK-1.08/blib/lib/SVK/Command/Propset.pm 
>>>line 99.
>>>readline() on unopened filehandle at 
>>>/root/.cpan/build/SVK-1.08/blib/lib/SVK/Command/Propset.pm line 99.
> 
> The got and expected results look the same, so it is surprising
> that this is a test failure.

It's a difference in line endings, of course.

> This is a bug (or at least an inadequacy) in Test::More, or Test::Harness, I would say.

Hmm, not sure. But it seems that as things stand, the onus is on the 
test writer to make the diagnostics clear.

>>The code in t/06keyword.t leading up to this looks like this:
> 
>>mkdir ("$copath/le");
>>overwrite_file_raw ("$copath/le/dos", "dos$CR");
>>overwrite_file_raw ("$copath/le/unix", "unix$CR");
>>overwrite_file_raw ("$copath/le/mac", "mac$CRLF");
> 
> These are wrong line endings that the test will try to change.
> The $Native on Unix in the next line will be $LF, which is \012.
> 
>>overwrite_file_raw ("$copath/le/native", "native$Native");
>>overwrite_file_raw ("$copath/le/na", "na$CR");
>>overwrite_file_raw ("$copath/le/mixed", "mixed$CRLF...endings$CR...");
>>$svk->add ("$copath/le");
>>$svk->ps ('svn:eol-style', 'CRLF', "$copath/le/dos");
>>$svk->ps ('svn:eol-style', 'native', "$copath/le/native");
>>$svk->ps ('svn:eol-style', 'LF', "$copath/le/unix");
>>$svk->ps ('svn:eol-style', 'CR', "$copath/le/mac");
>>$svk->ps ('svn:eol-style', 'NA', "$copath/le/na");
>>$svk->commit ('-m', 'test line ending', $copath);
> 
> Set right eol-styles.
> 
>>is_file_content_raw ("$copath/le/na", "na$CR");
>>SKIP: {
>># we don't update eolstyle=native files on lf-platforms,
>># or eolstyle=crlf files on crlf-platforms.
>># this should be done with checkout_delta/commit harvesting
>># the translated md5 to decide if they should be updated.
>>skip 'fix inconsistent eol-style after commit', 3;
> 
>>is_file_content_raw ("$copath/le/dos", "dos$CRLF");
>>is_file_content_raw ("$copath/le/unix", "unix$LF");
>>is_file_content_raw ("$copath/le/mac", "mac$CR");
>>}
> 
> I guess the test suite tested whether eol-style was being changed at some
> point, but these tests started failing (right eol-styles were not
> set) so they were skipped.
> 
>>is_file_content_raw ("$copath/le/native", "native$Native");
> 
>>$svk->ps ('svn:eol-style', 'CRLF', "$copath/le/native");
>>$svk->commit ('-m', 'test line ending', $copath);
>>is_file_content_raw ("$copath/le/native", "native$CRLF");
> 
> Presumably this test didn't start failing when the
> others started. I wonder how that could be.
> 
>>The contents of the file 't/checkout/keyword/le/native' is:
> 
>>  0000000   n   a   t   i   v   e  \n
>>  0000007
> 
> Is the \n a \012? I guess it is. The test expects the file to
> contain \015\012
> 
> echo -ne '\r\n' and echo -ne '\n' show the same result, so it is
> not surprising Test::More confuses us.
> 
>>and that doesn't change at all. I guess the test expects that it will?
> 
> It appears that setting eol-style property is broken (and more
> broken than it was before). Is working with different line
> endings important for you?

I work on Linux but there are a lot of Macs here and I sometimes import 
code with Windows line-endings. I'd rather not have to worry about a 
possibly broken filesystem changing things it shouldn't, or failing to 
change those it should.

I will hold off installing SVK until it's fixed, or at least unitl I 
fully understand the implications.

>>I'm a complete novice with both SVK and Subversion so I have no idea 
>>what the expected behaviour is or what might be going wrong. I'd 
>>appreciate any pointers.
> 
> For me, line endings are not a problem but I'm not working
> with files on different OS, like Windows and Unix.

Cheers, Dave