Re: Daily snapshots hosed (was Re: [pgadmin-hackers] Wh

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] 
> Sent: 08 October 2001 16:43
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org; The Hermit Hacker
> Subject: Daily snapshots hosed (was Re: [pgadmin-hackers] 
> [HACKERS] What about CREATE OR REPLACE FUNCTION?)
> 
> 
> Dave Page <dpage@vale-housing.co.uk> writes:
> > ... I can't find an up-to-date snapshot
> 
> > I tried postgresql.rmplc.co.uk and got one (apparently) 
> dated 7 Oct, 
> > however CREATE OR REPLACE FUNCTION didn't seem to be there (it 
> > certainly doesn't work anyway - syntax error at OR). I then 
> looked in 
> > the primary copy on mail.postgresql.org and found the copy 
> there was 
> > dated 30 Sept from which I assumed that the 07/10/2001 date on rm's 
> > copy was actually a US date - that site has been seriously 
> out of date 
> > before.
> 
> I just downloaded 
> ftp://ftp.us.postgresql.org/dev/postgresql-> snapshot.tar.gz
> 
> which has a date of yesterday in the FTP 
> archives, but actually contains a snapshot from around 15 
> September as near as I can tell. Looks like something is 
> hosed in the snapshot preparation process; Marc, could you 
> take a look at it?
> 
> >> and I don't know the
> >> magic that has to be worked on the PostgreSQL CVS version of the
> >> configure script in order to make it run without barfing.
> 
> > I always assumed that something is done when the tarballs 
> are built as 
> > the work just fine on the same machine.
> 
> No, the tarballs should be the same as what you get from a 
> CVS pull of the same date (other than not having a lot of 
> /CVS subdirectories). In fact, they're made basically by 
> tar'ing up a CVS checkout.  Please try diffing configure from 
> a tarball against one from CVS to see if you can figure out 
> what's getting munged during your CVS pull.
> 
> > The only odd thing I can think of is
> > that my copy of the source is maintained on my PC using 
> WinCVS and was 
> > zipped/ftp'd onto a test box.
> 
> LF vs CR/LF newlines leap to mind as a likely source of 
> trouble... though I'm not sure why that would manifest in 
> just this way...

This does appear to be the case, though where they came from I don't know!
My best guess is that WinCVS thought they'd be useful as I'm working on
Windows. Actually that would explain the issue we had with the ODBC driver
MSVC++ makefile some time ago...

Anyway, thanks Tom,

Dave.