Re-baseline tests that are producing correct/acceptable results on Windows....

Re-baseline tests that are producing correct/acceptable results on Windows.

BUG=15217, 4363, 9798, 18978
TEST=covered by layout tests

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=23104

[michaeln, 2009-08-11 07:43:10]

LGTM

http://codereview.chromium.org/164292/diff/11/18
File
webkit/data/layout_tests/platform/chromium-win/LayoutTests/fast/layers/video-layer-expected.txt
(right):

http://codereview.chromium.org/164292/diff/11/18#newcode1
Line 1: layer at (0,0) size 800x600
> Added: svn:eol-style
> + native

Is the native eol-style intentional... just checking.

So the test harness produces files with 'native' lines endings which are
compared to svn's expectation... is that right?

[Pam (message me for reviews), 2009-08-11 21:58:00]

http://codereview.chromium.org/164292/diff/11/18
File
webkit/data/layout_tests/platform/chromium-win/LayoutTests/fast/layers/video-layer-expected.txt
(right):

http://codereview.chromium.org/164292/diff/11/18#newcode1
Line 1: layer at (0,0) size 800x600
On 2009/08/11 07:43:10, michaeln wrote:
> > Added: svn:eol-style
> > + native
> 
> Is the native eol-style intentional... just checking.

Yes, all *.txt files in our repository are checked in with svn:eol-style native.

> So the test harness produces files with 'native' lines endings which are
> compared to svn's expectation... is that right?

It doesn't matter which line endings the harness produces. Once the file is
checked into svn with the svn:eol-style native property, it gets checked out
with "native" endings (LF on Unix, CRLF on Windows, CR on Mac) in each person's
working copy.

But then when the harness takes those files and compares them to what's produced
in the next run, it normalizes all line endings in both pieces to \n anyway.
(See layout_package/test_types/text_diff.py.)

- Pam