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

Поиск
Список
Период
Сортировка
От geek+@cmu.edu
Тема Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Дата
Msg-id emacs-smtp-22924-14045-15463-819491@export.andrew.cmu.edu
обсуждение исходный текст
Ответ на Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
Список pgsql-hackers
Then <lockhart@alumni.caltech.edu> spoke up and said:
> > Modified Files:
> >         parse.h gram.c
> > Log Message:
> > Someone forgot to commit gram.c and parse.h after his latest
> > set of updates to gram.y.
> 
> I didn't forget! istm that we risk cvs bloat by checking in derived
> files like gram.c, when there are probably minor differences in how each
> system generates them. So I don't usually check in those files when we
> are deep in the middle of hacker development. Of course, that could be
> the wrong thing to (not) do...

You *never* want to check in derived files when using CVS.  Instead,
create checkout rules (see the cvs docs) to automatically create those
files upon checkin/checkout, whichever is more appropriate.

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@andrew.cmu.edu for my public key.                     |
=====================================================================

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

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] int 8 on FreeBSD
Следующее
От: Vince Vielhaber
Дата:
Сообщение: pg_dumpall and restoring