Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c' - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Date
Msg-id 26750.920504696@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
List pgsql-hackers
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>> I'm using cvs 1.10 here, but I don't think its behavior has changed
>> in this respect in any recent version.  If it did not timestamp 
>> updates with time of retrieval, it would create synchronization bugs 
>> with respect to locally created files, which'd be no fun either.

> I use CVSup, and it seems to keep the creation date of files consistant
> with the source cvs tree. Does anonymous cvs not do that?

I don't know anything about CVSup, but plain cvs works the way I
described, and *should* work the way I described.  Otherwise, when
you update a ".c" file from the repository, it might not look like
it's newer than the corresponding ".o" file that you generated locally
(since that could have been made later than someone else committed a
change to the .c file).

If CVSup timestamps files with their repository timestamps, then the
only safe way to use it is to "make distclean" and rebuild from scratch
after every update.  (Of course that's probably a good idea anyway since
we aren't maintaining reliable dependency info in the makefiles, but we
shouldn't get forced into it because of a misdesigned tool.)

> btw, could all of this be traced to bad dependencies on parse.h?

No.  The problem was that parse.h itself was not up-to-date.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] palloc.h again
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Tom Lane's fixes in v6.4.3