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

Поиск
Список
Период
Сортировка
От Thomas G. Lockhart
Тема Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Дата
Msg-id 36DD68D2.E5583B4B@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> I don't think it's cvs' fault.
> 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? Again, I
*don't* see the behavior that you do, at least given my CVSup/cvs-1.9
system.

> 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.

Sure. Who wants to work that out?

btw, could all of this be traced to bad dependencies on parse.h? Our
current Makefile system does not do this correctly. I applied some small
patches recently to help, but it did not fix the fundamental problem
that all the backend/* directories refer to backend/parse.h, but they do
not know that backend/parse.h is a copy of backend/parser/parse.h.
                       - Tom


В списке pgsql-hackers по дате отправления:

Предыдущее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] palloc.h again
Следующее
От: Kaare Rasmussen
Дата:
Сообщение: Re: [HACKERS] NUMERIC and Perl