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'
|
Список | 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 по дате отправления: