> On Mon, 31 Jan 2000, Tom Lane wrote:
>
> > The Hermit Hacker <scrappy@hub.org> writes:
> > >> I disagree on _deadcode. While the code is rotted, it does implement
> > >> some full functions that have no other history, like verion.c for
> > >> versioning and xfunc for expensive functions. Yanking them means we can
> > >> never know what they did.
> >
> > > even 'yanked' code is still in the cvs repository ...
> >
> > Precisely. Seems to me we ought to think about our code maintenance
> > methods with knowledge that back versions will be available from CVS.
> > Keeping stuff in the current tree has some advantages if it's stuff
> > you think you might want again in the near term, but I think it's
> > the wrong way to deal with stuff that we're only keeping for historical
> > purposes. For example, if I wanted to try to understand the xfunc
> > code, I'd really have to go back to the last version where it worked;
> > the partially-patched files sitting in _deadcode would most likely be
> > more confusing than helpful...
>
> have to agree here ... how much of the NOT_USED code is totally irrelevant
> based on the changes around it?
>
> Some sort of 'text log' of what is removed and date should be kept, if ppl
> want to be able to go back ... basically, instead of 'moved to _deadcode',
> just add a line to a text file stating 'function X removed on date Y' so
> that ppl have a guide to look at the cvs repository with ...
I am thinking of going through the code and removing NOT_USED functions
I know to be useless. OK?
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026