Thread: pgsql/src/backend/optimizer/prep/_deadcode pre ...

pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
tgl@postgresql.org (Tom Lane)
Date:
CVSROOT:    /cvsroot
Module name:    pgsql
Changes by:    tgl@postgresql.org    02/07/30 14:54:59

Removed files:
    src/backend/optimizer/prep/_deadcode: prepkeyset.c

Log message:
    If we're cleaning out _deadcode, might as well zap this one too.


Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> CVSROOT:    /cvsroot
> Module name:    pgsql
> Changes by:    tgl@postgresql.org    02/07/30 14:54:59
>
> Removed files:
>     src/backend/optimizer/prep/_deadcode: prepkeyset.c
>
> Log message:
>     If we're cleaning out _deadcode, might as well zap this one too.

Uh, that was the one for KSQO.  Did we want to keep that?  I guess not
but will just have to remember it is in CVS.  I was thinking we should
add a file at the top of /src listing the files we have removed but are
in CVS for later reuse.  Comments?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  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, Pennsylvania 19026

Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> If we're cleaning out _deadcode, might as well zap this one too.

> Uh, that was the one for KSQO.  Did we want to keep that?

I didn't.

> I guess not
> but will just have to remember it is in CVS.  I was thinking we should
> add a file at the top of /src listing the files we have removed but are
> in CVS for later reuse.  Comments?

Seems like a waste of time --- the potentially useful stuff in back
archived versions is not cleanly organized into files that we deleted
(vs ones we still have).  Will you want to start including a log of
every code deletion?

            regards, tom lane

Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> If we're cleaning out _deadcode, might as well zap this one too.
>
> > Uh, that was the one for KSQO.  Did we want to keep that?
>
> I didn't.
>
> > I guess not
> > but will just have to remember it is in CVS.  I was thinking we should
> > add a file at the top of /src listing the files we have removed but are
> > in CVS for later reuse.  Comments?
>
> Seems like a waste of time --- the potentially useful stuff in back
> archived versions is not cleanly organized into files that we deleted
> (vs ones we still have).  Will you want to start including a log of
> every code deletion?

I bring it up because code deletions show up in the 'cvs log' of the
still-existing file, while file deletions really are invisible unless
you know the file was there before.  I assume this was Marc's reason for
objecting to the file removals in the first place.  Not sure I agree,
but I see the point.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  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, Pennsylvania 19026

Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I bring it up because code deletions show up in the 'cvs log' of the
> still-existing file, while file deletions really are invisible unless
> you know the file was there before.

Which you can find out by looking in the "Attic" subdirectory.  I don't
think file removals are any "more invisible" in CVS than code removals
within a file.

            regards, tom lane

Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I bring it up because code deletions show up in the 'cvs log' of the
> > still-existing file, while file deletions really are invisible unless
> > you know the file was there before.
>
> Which you can find out by looking in the "Attic" subdirectory.  I don't
> think file removals are any "more invisible" in CVS than code removals
> within a file.

I don't see any Attic directory in my CVS.  Do I have to look in the CVS
tree?  If so, it is more invisible.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  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, Pennsylvania 19026

Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't see any Attic directory in my CVS.  Do I have to look in the CVS
> tree?  If so, it is more invisible.

A checked-out copy of CVS doesn't have any history in it anyway; you
always have to go to the server (or a local cvsup repository) to see
the history.  So I don't really see the difference here.

Even more to the point, if we really thought those files would be of
future interest, they'd not have gotten removed in the first place.
We'd just have done #ifdef NOT_USED or some such.  I don't see much
point in a manually maintained (and therefore surely incomplete and
inaccurate) index to uninteresting code...

            regards, tom lane

Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I don't see any Attic directory in my CVS.  Do I have to look in the CVS
> > tree?  If so, it is more invisible.
>
> A checked-out copy of CVS doesn't have any history in it anyway; you
> always have to go to the server (or a local cvsup repository) to see
> the history.  So I don't really see the difference here.

Yes, but from my command line, I can see the changes made to any file.
How do I see attic files from the command line?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  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, Pennsylvania 19026

Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, but from my command line, I can see the changes made to any file.
> How do I see attic files from the command line?

cvs log doesn't seem to have any problem with that.

$ cd ~/pgsql/src/backend/commands
$ cvs log | grep Attic
cvs server: Logging .
RCS file: /cvsroot/pgsql/src/backend/commands/Attic/Makefile.inc,v
RCS file: /cvsroot/pgsql/src/backend/commands/Attic/async.h,v
... etc ...

$ cvs log async.h

RCS file: /cvsroot/pgsql/src/backend/commands/Attic/async.h,v
Working file: async.h
... etc ...
revision 1.2
date: 1996/08/28 07:16:07;  author: scrappy;  state: dead;  lines: +1 -1
Clean up th ecompile process by centralizing the include files

        - code compile tested, but due to a yet unresolved problem with
          parse.h's creation, compile not completed...
----------------------------

$

            regards, tom lane

Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From
Bruce Momjian
Date:
I see, the log shows the file and the info about it.  Makes sense.  It
is just one more step to finding the file.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Yes, but from my command line, I can see the changes made to any file.
> > How do I see attic files from the command line?
>
> cvs log doesn't seem to have any problem with that.
>
> $ cd ~/pgsql/src/backend/commands
> $ cvs log | grep Attic
> cvs server: Logging .
> RCS file: /cvsroot/pgsql/src/backend/commands/Attic/Makefile.inc,v
> RCS file: /cvsroot/pgsql/src/backend/commands/Attic/async.h,v
> ... etc ...
>
> $ cvs log async.h
>
> RCS file: /cvsroot/pgsql/src/backend/commands/Attic/async.h,v
> Working file: async.h
> ... etc ...
> revision 1.2
> date: 1996/08/28 07:16:07;  author: scrappy;  state: dead;  lines: +1 -1
> Clean up th ecompile process by centralizing the include files
>
>         - code compile tested, but due to a yet unresolved problem with
>           parse.h's creation, compile not completed...
> ----------------------------
>
> $
>
>             regards, tom lane
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  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, Pennsylvania 19026