Re: [COMMITTERS] pgsql: Second try committing the path
От | Andrew Dunstan |
---|---|
Тема | Re: [COMMITTERS] pgsql: Second try committing the path |
Дата | |
Msg-id | 44F725E1.8020900@dunslane.net обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Second try committing the path changes. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Second try committing the path
|
Список | pgsql-hackers |
Tom Lane wrote: > Chris Browne <cbbrowne@acm.org> writes: > >> tgl@sss.pgh.pa.us (Tom Lane) writes: >> >>> No, because those derived files are not in CVS at all. What you >>> are describing sounds to me like a clock skew problem. Is your >>> machine's system clock showing the correct date? >>> > > >> Odd, odd. NOT a clock problem. The .c files were sitting in my >> buildfarm's CVS repository for HEAD. And yes, indeed, the derived >> files shouldn't have been there at all. I'm not quite sure how they >> got there in the first place. >> > > >> At any rate, after comprehensively looking for yacc-derived files, >> that clears this problem, as well as regression failures with last >> night's commit of COPY (SELECT) TO, which is no bad thing. >> > > I'll bet the way they got there is you did a build in the CVS repository > tree, and then cleaned up with "make distclean" not "make maintainer-clean". > > The buildfarm script is supposed to complain about unexpected files in > the repository --- I wonder if it is fooled by the .cvsignore entries > for these files? > > regards, tom lane > > Yes, we do. A patch made in July 2005 has this comment: "ignore files listed in cvsignore files - this will stop inappropriate triggering of vpath builds." Perhaps I should only do that for vpath builds. Or perhaps I should even remove them at the end of a build, since we don't expect any of those files in a clean repo, do we? Also, in case anyone has not got the message yet: Don't ever build by hand in the buildfarm repo. Ever. I mean it. Use a copy. cheers andrew
В списке pgsql-hackers по дате отправления: