Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c' |
Дата | |
Msg-id | 26750.920504696@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c' ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | 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 по дате отправления: