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

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 08 October 2001 16:43
> To: Dave Page
> Cc: pgsql-hackers(at)postgresql(dot)org; The Hermit Hacker
> Subject: Daily snapshots hosed (was Re: [pgadmin-hackers]
> [HACKERS] What about CREATE OR REPLACE FUNCTION?)
>
>
> Dave Page <dpage(at)vale-housing(dot)co(dot)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.