Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>> Well, if you want to know why I was annoyed, I'll explain.
>> On my machine, gram.c/parse.h appeared to be newer than gram.y.
>> Since gram.c/parse.h were in fact *not* up-to-date with respect
>> to header-file changes elsewhere, they didn't compile.

> Oh! I haven't seen that behavior before, and am not sure why you did :(
> If I updated gram.y, but did not update gram.c, then cvs and CVSup
> should never bollix up the times on the files afaik.

I don't think it's cvs' fault.  The recent checkin times for gram.y are:
2.57 1999/02/23 07:42:41;  author: thomas
2.56 1999/02/21 03:49:00;  author: scrappy
2.55 1999/02/13 23:17:03;  author: momjian
2.54 1999/02/08 14:14:12;  author: wieck
2.53 1999/02/07 19:02:19;  author: wieck

and gram.c:
2.75 1999/02/27 21:33:53;  author: tgl
2.74 1999/02/22 05:26:33;  author: momjian
2.73 1999/02/14 05:14:09;  author: momjian
2.72 1999/02/13 23:16:54;  author: momjian
2.71 1999/02/09 06:30:40;  author: momjian
2.70 1999/02/09 03:51:30;  author: momjian
2.69 1999/02/07 19:04:59;  author: wieck

Unfortunately I do not have a log of when I recently did "cvs update"s
(unless someone knows a way to extract that info from cvs itself)?
But I will bet that when I updated on 2/24, it had been more than two
days since my previous update, and so cvs updated both gram.y (to 2.57)
and gram.c (to 2.74, that being Bruce's latest commit) in the same
update cycle.  Since cvs timestamps updated files with the time of
*retrieval*, gram.c ended up having a slightly newer timestamp locally
than gram.y, and so make didn't think it needed to be rebuilt.

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 still stand by my observation: either gram.c is a derived file and
shouldn't be in the CVS repository at all, or else it is a master file
and must be maintained just as faithfully as any other source file.
There is no middle ground that will work reliably with CVS.  Especially
not in the face of multiple authors some of whom commit the derived file
and some of whom don't.
        regards, tom lane

PS: treating gram.c as a derived file that is made while building
a tarball would also eliminate our recurring problem with gram.c
appearing to be out-of-date in releases, when it really isn't.