Thread: pgsql-server/doc/src/sgml Makefile
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: momjian@svr1.postgresql.org 04/03/05 15:48:03
Modified files:
doc/src/sgml : Makefile
Log message:
Use '-' for stdin on lynx, my lynx version doesn't support -stdin.
momjian@svr1.postgresql.org (Bruce Momjian) writes:
> Use '-' for stdin on lynx, my lynx version doesn't support -stdin.
How old is your lynx? I checked before making that patch, and -stdin
seemed to be in the oldest lynx I had handy (RHL 8.0).
BTW, I recently installed 2.8.5rel.1 here, and it generates very clean
text output --- no weird trailing spaces, proper justification of
headings, etc. I'd suggest standardizing on that for building the
HISTORY file.
regards, tom lane
Tom Lane wrote:
> momjian@svr1.postgresql.org (Bruce Momjian) writes:
> > Use '-' for stdin on lynx, my lynx version doesn't support -stdin.
>
> How old is your lynx? I checked before making that patch, and -stdin
> seemed to be in the oldest lynx I had handy (RHL 8.0).
I am using:
Lynx Version 2.8.3rel.1 (23 Apr 2000)
I assume bsdi kept that version perhaps because newer versions had
troubles with some things.
In the old days, only I did HISTORY. Now that others are doing it,
which is good, we should standardize to prevent CVS from recording
massive changes to HISTORY for different versions of lynx.
> BTW, I recently installed 2.8.5rel.1 here, and it generates very clean
> text output --- no weird trailing spaces, proper justification of
> headings, etc. I'd suggest standardizing on that for building the
> HISTORY file.
I see on postgresql.org:
Lynx Version 2.8.5dev.16 (01 Jun 2003)
I used that to generate HISTORY, and I did a diff against the HISTORY I
generated, and the only difference is that it doesn't have spaces on
blank lines, which is even better output than mine.
In the future, I will use postgresql.org lynx. If you find yours
generates similar output to that, you can keep using your local one.
I have changed the lynx flag back to -stdin, and regenerated HISTORY, so
you can run a comparison with CVS to see if yours is similar.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I see on postgresql.org:
> Lynx Version 2.8.5dev.16 (01 Jun 2003)
> I used that to generate HISTORY, and I did a diff against the HISTORY I
> generated, and the only difference is that it doesn't have spaces on
> blank lines, which is even better output than mine.
> In the future, I will use postgresql.org lynx. If you find yours
> generates similar output to that, you can keep using your local one.
Actually, mine generates better output than that one --- it aligns
headings better. I'd suggest updating to the 2.8.5 release.
The HISTORY versions that I just committed were made with 2.8.5rel1
... feel free to compare.
regards, tom lane
Bruce Momjian wrote: > In the old days, only I did HISTORY. Now that others are doing it, > which is good, we should standardize to prevent CVS from recording > massive changes to HISTORY for different versions of lynx. A better approach for that would be to remove HISTORY from CVS and build it only when the release tarball is made.
Peter Eisentraut <peter_e@gmx.net> writes:
> A better approach for that would be to remove HISTORY from CVS and build
> it only when the release tarball is made.
Given some standardization of the toolchain, that would be the way to
go. Right now, though, we seem to have some doubts at both the SGML
and lynx levels. Can we clear these up so people know what they will
get?
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > A better approach for that would be to remove HISTORY from CVS and build > > it only when the release tarball is made. > > Given some standardization of the toolchain, that would be the way to > go. Right now, though, we seem to have some doubts at both the SGML > and lynx levels. Can we clear these up so people know what they will > get? I think the only reason HISTORY and INSTALL are in CVS is because we want people running CVS during beta to have changes docs and install instructions that don't require them to pull down a new tarball each time or read the docs via a web site. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> A better approach for that would be to remove HISTORY from CVS and build
>>> it only when the release tarball is made.
> I think the only reason HISTORY and INSTALL are in CVS is because we
> want people running CVS during beta to have changes docs and install
> instructions that don't require them to pull down a new tarball each
> time or read the docs via a web site.
That argument seems a bit silly for HISTORY, seeing that it's generally
not up-to-date during beta testing. As for INSTALL, those instructions
don't change fast enough to surprise beta testers, so I'm not convinced
about it either.
regards, tom lane