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

From geek+@cmu.edu
Subject Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Date
Msg-id emacs-smtp-22924-14045-15463-819491@export.andrew.cmu.edu
Whole thread Raw
In response to Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
List 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 by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] int 8 on FreeBSD
Next
From: Vince Vielhaber
Date:
Subject: pg_dumpall and restoring