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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Дата
Msg-id 24524.920443982@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  (The Hermit Hacker <scrappy@hub.org>)
Список pgsql-hackers
The Hermit Hacker <scrappy@hub.org> writes:
> On Wed, 3 Mar 1999, Thomas G. Lockhart wrote:
>>>> 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,

> Would have to agree here...developers *should* have the tools on their
> systems required to generate this...these should only be
> generated/committed as part of our pre-release checklist...
> I think there are slightly more important things to worry about during
> development...no? :)

Well, if you want to know why I was annoyed, I'll explain.

On my machine, gram.c/parse.h appeared to be newer than gram.y.
Just a chance artifact of when I happened to do cvs updates,
no doubt.  (It doesn't help that cvs nearly always updates gram.y
first when it has to update them all --- it probably gave me
version N of gram.y and version N-1 of the derived files in the
same update run, while managing to make the derived files look
newer.)

Since gram.c/parse.h were in fact *not* up-to-date with respect
to header-file changes elsewhere, they didn't compile.

I thought this was breakage due to Bruce's removal of recipe.h/.c,
and griped accordingly last Tuesday or so.  It wasn't till Saturday
that I realized the guys whom I was expecting to fix it were on
vacation and I had better do my own digging.  Now it didn't take me
a lot of hours to realize what was wrong, but it very easily could've
--- and in any case I'd already spent a couple of evenings doing other
stuff when I had wanted to work on Postgres.

My feeling is this: if you want to remove gram.c/parse.h from the
CVS file set entirely, expecting developer types to have the
necessary tools, that's a defensible approach.  (Tarball drops
could and should include freshly-generated copies, of course.)
Or, if you want to keep them in CVS and *keep them up to date*,
that works for me too.  But don't be wishy-washy.  You're just
wasting download time and developer time if you don't treat
these files consistently.
        still fairly annoyed, tom lane


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

Предыдущее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] datetime.c in v6.4.3beta2 ...
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] datetime.c in v6.4.3beta2 ...