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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] palloc.h again
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Tom Lane's fixes in v6.4.3