Re: [PATCHES] HEAD doesn't cope with libraries in non-default - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [PATCHES] HEAD doesn't cope with libraries in non-default
Date
Msg-id 42D54E41.7010700@dunslane.net
Whole thread Raw
In response to Re: [PATCHES] HEAD doesn't cope with libraries in non-default  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries in non-default
List pgsql-hackers

Jim C. Nasby wrote:

>Turns out there was a cvs conflict. Doh!
>  
>

Ouch. I have repeatedly warned buildfarm owners not to make any changes 
or run builds in buildfarm's local CVS repo. Use a copy if necessary.

>Hmm... would probably be a good idea to have the script check for
>conflicts and throw a CVS error if it finds any. Here's what CVS does on
>a conflict:
>
>RCS file: /projects/cvsroot/pgsql/src/Makefile.shlib,v
>retrieving revision 1.93
>retrieving revision 1.94
>Merging differences between 1.93 and 1.94 into Makefile.shlib
>rcsmerge: warning: conflicts during merge
>cvs update: conflicts found in Makefile.shlib
>C Makefile.shlib
>
>It also creates a .# file. I'm not really sure what the best way to test
>for this would be.
>  
>

I can look for it. It's a pity that cvs doesn't exit with a non-zero 
status when it does this. I am assuming we don't ever have such files in 
CVS.

>BTW, it would probably be handy to have logs available for all steps of
>the build, even if they succeed.
>  
>

They are available locally in the directory lastrun-logs. I made a 
deliberate decision not to clog up the server with them. At roughly 1Mb 
per build it seemed quite unnecessary - I wanted to keep traffic down 
and server storage requirements modest.

>In any case, I've cleared the conflict and I'm running a build right
>now.
>
>  
>
>

OK, cool.


cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] HEAD doesn't cope with libraries in non-default
Next
From: Oleg Bartunov
Date:
Subject: Re: SQL99 - Nested Tables