Re: Cause of recent buildfarm failures on hamerkop - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Cause of recent buildfarm failures on hamerkop
Date
Msg-id CAC_2qU-bmH+inNzZvhxirOd6vrjNjz+mYkM3tAjwo+F=2qGXZg@mail.gmail.com
Whole thread Raw
In response to Re: Cause of recent buildfarm failures on hamerkop  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Cause of recent buildfarm failures on hamerkop  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Sep 14, 2012 at 4:56 AM, Magnus Hagander <magnus@hagander.net> wrote:

>> I assume this means that the git checkout was created with options that
>> allowed conversion of text files to \r\n line endings.

If we have "text files" that we need to be "binary equivilents" for
the purpose of diffing, we should probably attribute them in git
attributes to make sure they are not considered "text autocrlf'able".
It could be as simple as adding:   *.out    -text   *.data   -text   *.source -text
into src/test/regress/.gitattributes

>> I'm not sure if we should just write this off as pilot error, or if we
>> should try to make the regression tests proof against such things.  If
>> the latter, how exactly?
>
> I don't think we need to make them proof against it. But it wouldn't
> hurt to have a check that threw a predictable error when it happens.
> E.g. a first step in the regression tests that just verifies what kind
> of line endings are in a file. Could maybe be as simple as checking
> the size of the file?

This leads to making sure you keep your "verification list" in source,
and up-to-date too...

a.



-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.



pgsql-hackers by date:

Previous
From: Amit kapila
Date:
Subject: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Next
From: Bruce Momjian
Date:
Subject: contrib translations