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 ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org