Re: Cause of recent buildfarm failures on hamerkop

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, harukat(at)sraoss(dot)co(dot)jp
Subject: Re: Cause of recent buildfarm failures on hamerkop
Date: 2012-09-14 13:27:51
Message-ID: CAC_2qU-bmH+inNzZvhxirOd6vrjNjz+mYkM3tAjwo+F=2qGXZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 14, 2012 at 4:56 AM, Magnus Hagander <magnus(at)hagander(dot)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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-09-14 13:37:18 contrib translations
Previous Message Amit kapila 2012-09-14 13:01:37 Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown