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