CVS in docs
Do references to the CVS need removing now that everything is on GIT?
Is the CVS page still relevant?
http://www.postgresql.org/docs/9.0/static/anoncvs.html (cvs.sgml)
This refers to that page and the anoncvs web interface:
http://www.postgresql.org/docs/9.0/static/release.html (release.sgml)
The installation page talks about building from a CVS tree:
http://www.postgresql.org/docs/9.0/static/install-requirements.html
(installation.sgml)
HOT (Heap-Only Typles) in acronyms (acronyms.sgml) links to anoncvs,
so maybe point it to
http://git.postgresql.org/gitweb?p=postgresql.git;a=blob_plain;f=src/backend/access/heap/README.HOT;hb=HEAD
NLS info for translators refers to CVS:
http://www.postgresql.org/docs/9.0/static/nls-translator.html
(nls.sgml)
Bug reporting mentions CVS:
http://www.postgresql.org/docs/9.0/static/bug-reporting.html
(problems.sgml)
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
Thom Brown <thom@linux.com> writes:
Do references to the CVS need removing now that everything is on GIT?
The chapter about CVS obviously needs to be replaced. I was talking
to Magnus about that earlier, and we both felt that that needs to be
back-patched, if only so that there are non-obsolete repository URLs
in the next back-branch updates. I'm not sure that we need the
tutorial-ish description of how to do checkouts etc, but at the least
we need the URLs.
A quick grep suggests that there are a dozen or two other passing
references to CVS in docs and comments, which'd be worth cleaning
up in HEAD, but probably not worth back-patching.
regards, tom lane
On Wed, Sep 22, 2010 at 00:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thom Brown <thom@linux.com> writes:
Do references to the CVS need removing now that everything is on GIT?
The chapter about CVS obviously needs to be replaced. I was talking
to Magnus about that earlier, and we both felt that that needs to be
back-patched, if only so that there are non-obsolete repository URLs
in the next back-branch updates. I'm not sure that we need the
tutorial-ish description of how to do checkouts etc, but at the least
we need the URLs.
Here's a suggested patch for this. Most of it is just taking out the
cvs documentation since most of the git info was in there already. I
also moved some notes around.
Finally, I took the liberty to rip out the <appendixinfo> part listing
specific authors. Most of what they did is gone now anyway, and we
don't have those entries on other files.
A quick grep suggests that there are a dozen or two other passing
references to CVS in docs and comments, which'd be worth cleaning
up in HEAD, but probably not worth back-patching.
Agreed.
What about the messages in configure?
"configure:*** Without Bison you will not be able to build PostgreSQL
from CVS nor"
coming out of config/*.m4?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
git_docs.patchtext/x-patch; charset=US-ASCII; name=git_docs.patchDownload+29-207
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2010 at 00:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
A quick grep suggests that there are a dozen or two other passing
references to CVS in docs and comments, which'd be worth cleaning
up in HEAD, but probably not worth back-patching.
Agreed.
What about the messages in configure?
"configure:*** Without Bison you will not be able to build PostgreSQL
from CVS nor"
I was lumping those in the "not worth back-patching" category, but
if you're excited about them, feel free to back-patch.
regards, tom lane
On Wed, Sep 22, 2010 at 15:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2010 at 00:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
A quick grep suggests that there are a dozen or two other passing
references to CVS in docs and comments, which'd be worth cleaning
up in HEAD, but probably not worth back-patching.Agreed.
What about the messages in configure?
"configure:*** Without Bison you will not be able to build PostgreSQL
from CVS nor"I was lumping those in the "not worth back-patching" category, but
if you're excited about them, feel free to back-patch.
Ok. I'll see - I need to get an old version of autoconf going too - I
somehow managed to wipe the one I have, and Ubuntu ships with a
different version :-)
I take the lack of comment on the patch itself as silent approval, so
I'll go look at backporting it soon.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 22 September 2010 15:07, Magnus Hagander <magnus@hagander.net> wrote:
On Wed, Sep 22, 2010 at 15:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2010 at 00:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
A quick grep suggests that there are a dozen or two other passing
references to CVS in docs and comments, which'd be worth cleaning
up in HEAD, but probably not worth back-patching.Agreed.
What about the messages in configure?
"configure:*** Without Bison you will not be able to build PostgreSQL
from CVS nor"I was lumping those in the "not worth back-patching" category, but
if you're excited about them, feel free to back-patch.Ok. I'll see - I need to get an old version of autoconf going too - I
somehow managed to wipe the one I have, and Ubuntu ships with a
different version :-)I take the lack of comment on the patch itself as silent approval, so
I'll go look at backporting it soon.
I don't see any mention of redirecting the Heap-Only Tuples glossary
reference link. Is that staying as it is?
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
On Wed, Sep 22, 2010 at 16:10, Thom Brown <thom@linux.com> wrote:
On 22 September 2010 15:07, Magnus Hagander <magnus@hagander.net> wrote:
On Wed, Sep 22, 2010 at 15:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2010 at 00:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
A quick grep suggests that there are a dozen or two other passing
references to CVS in docs and comments, which'd be worth cleaning
up in HEAD, but probably not worth back-patching.Agreed.
What about the messages in configure?
"configure:*** Without Bison you will not be able to build PostgreSQL
from CVS nor"I was lumping those in the "not worth back-patching" category, but
if you're excited about them, feel free to back-patch.Ok. I'll see - I need to get an old version of autoconf going too - I
somehow managed to wipe the one I have, and Ubuntu ships with a
different version :-)I take the lack of comment on the patch itself as silent approval, so
I'll go look at backporting it soon.I don't see any mention of redirecting the Heap-Only Tuples glossary
reference link. Is that staying as it is?
Ah, good point. No, let's change that.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
<!-- appendixes --> <!entity contacts SYSTEM "contacts.sgml"> -<!entity cvs SYSTEM "cvs.sgml"> +<!entity sourcerepo SYSTEM "sourcerepo.sgml"> <!entity datetime SYSTEM "datetime.sgml"> <!entity docguide SYSTEM "docguide.sgml"> <!entity errcodes SYSTEM "errcodes.sgml">
Please keep the filelist entries in alphabetical order.
<!-- we need a file containing the CVS logs for each release, and something
like the SVN web interface that groups commits but has branches -->
This comment should be updated, or deleted entirely.
I didn't attempt to read the changes in sourcerepo.sgml ... as you well
know, I find diff -u format utterly unreadable for more than one-liner
changes.
regards, tom lane
On Wed, Sep 22, 2010 at 17:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
<!-- appendixes --> <!entity contacts SYSTEM "contacts.sgml"> -<!entity cvs SYSTEM "cvs.sgml"> +<!entity sourcerepo SYSTEM "sourcerepo.sgml"> <!entity datetime SYSTEM "datetime.sgml"> <!entity docguide SYSTEM "docguide.sgml"> <!entity errcodes SYSTEM "errcodes.sgml">Please keep the filelist entries in alphabetical order.
Ack.
<!-- we need a file containing the CVS logs for each release, and something
like the SVN web interface that groups commits but has branches -->This comment should be updated, or deleted entirely.
Given that I don't even understand what it means and what it does
there, I deleted it :)
I didn't attempt to read the changes in sourcerepo.sgml ... as you well
know, I find diff -u format utterly unreadable for more than one-liner
changes.
Sorry about that. It's basically just deleting all the references to
cvs - the git chapter was there already - and moving the info about
bison/flex/perl requirements to the first section.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Sep 22, 2010 at 19:29, Magnus Hagander <magnus@hagander.net> wrote:
On Wed, Sep 22, 2010 at 17:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
I didn't attempt to read the changes in sourcerepo.sgml ... as you well
know, I find diff -u format utterly unreadable for more than one-liner
changes.Sorry about that. It's basically just deleting all the references to
cvs - the git chapter was there already - and moving the info about
bison/flex/perl requirements to the first section.
Looking at backpatching this, I realized the major changes we made to
it a while ago was only backpatched to 8.4. 8.3 and earlier has the
much more complex cvs instructoins.
I suggest just wiping those and replacing them with the same git
instructions we have now. Objections?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Excerpts from Magnus Hagander's message of mié sep 22 13:29:00 -0400 2010:
On Wed, Sep 22, 2010 at 17:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
<!-- we need a file containing the CVS logs for each release, and something
like the SVN web interface that groups commits but has branches -->This comment should be updated, or deleted entirely.
Given that I don't even understand what it means and what it does
there, I deleted it :)
I think this is about having some sort of pointer to a ChangeLog or
similar resource (so that someone interested can see the commits for
each branch). I didn't look at your patch, but if you provide a pointer
to the Git "summary", that seems enough.
BTW now that they are pestered with the PgFoundry commit messages, the
pgsql-committers archive do not seem a very useful resource anymore.
The Git "shortlog" seems much better, so maybe we should point to that.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Magnus Hagander <magnus@hagander.net> writes:
Looking at backpatching this, I realized the major changes we made to
it a while ago was only backpatched to 8.4. 8.3 and earlier has the
much more complex cvs instructoins.
I suggest just wiping those and replacing them with the same git
instructions we have now. Objections?
Works for me.
regards, tom lane
Alvaro Herrera <alvherre@commandprompt.com> writes:
BTW now that they are pestered with the PgFoundry commit messages, the
pgsql-committers archive do not seem a very useful resource anymore.
The Git "shortlog" seems much better, so maybe we should point to that.
Hmm ... do we have a search engine for the shortlog? Anyway, anybody
who knows git at all will already know about looking at the git log.
I think the separate pointer to the committers archives is still of
use here.
regards, tom lane
On Wed, Sep 22, 2010 at 20:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Looking at backpatching this, I realized the major changes we made to
it a while ago was only backpatched to 8.4. 8.3 and earlier has the
much more complex cvs instructoins.I suggest just wiping those and replacing them with the same git
instructions we have now. Objections?Works for me.
Applied.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2010 at 20:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
I suggest just wiping those and replacing them with the same git
instructions we have now. Objections?Works for me.
Applied.
Uh, why only back to 8.2?
regards, tom lane
On Wed, Sep 22, 2010 at 20:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2010 at 20:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
I suggest just wiping those and replacing them with the same git
instructions we have now. Objections?Works for me.
Applied.
Uh, why only back to 8.2?
Based on the "the others are discontinued just over a month from now anyway"...
BTW, there are a ton of conflicts backpatching each step. I actually
had a conflict with a $PostgreSQL$ tag once in the Makefile going back
to 8.4 - so that does happen. But only once - the rest is all "proper"
conflicts.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2010 at 20:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Uh, why only back to 8.2?
Based on the "the others are discontinued just over a month from now anyway"...
Yeah, but they will each have a final release. Don't we want to have
the updated info in the final releases? I don't care about the
incidental CVS mentions, but replacing cvs.sgml with that new chapter
seems worth the trouble.
BTW, there are a ton of conflicts backpatching each step.
Welcome to the fun of back-patching. Did you get any leverage from
cherry-picking, or did it seem to be just as stupid as plain "patch"?
regards, tom lane
On Wed, Sep 22, 2010 at 20:37, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2010 at 20:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Uh, why only back to 8.2?
Based on the "the others are discontinued just over a month from now anyway"...
Yeah, but they will each have a final release. Don't we want to have
the updated info in the final releases? I don't care about the
incidental CVS mentions, but replacing cvs.sgml with that new chapter
seems worth the trouble.
Hmm. yeah. I'll look at doing it back to 7.4 then. I'll do the
incidental mentions as well if they merge cleanly :-)
BTW, there are a ton of conflicts backpatching each step.
Welcome to the fun of back-patching. Did you get any leverage from
Oh, it's not the first time. I just wanted to make note that one, but
only one, conflicted on the $PostgreSQL$ tag.
cherry-picking, or did it seem to be just as stupid as plain "patch"?
It *seemed* smarter. But I didn't try to backpatchthe same thing both
ways, so it's hard to tell for sure.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Alvaro Herrera wrote:
BTW now that they are pestered with the PgFoundry commit messages, the
pgsql-committers archive do not seem a very useful resource anymore.
The Git "shortlog" seems much better, so maybe we should point to that.
I missed why that happened in the first place, but based on being a
subscriber isn't that something that should be split onto another list
regardless? The chatter added to pgsql-committers from everything there
really seems inappropriate. A new pgsql-pgfoundry for all those instead
perhaps?
--
Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance" Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book
Greg Smith <greg@2ndquadrant.com> writes:
Alvaro Herrera wrote:
BTW now that they are pestered with the PgFoundry commit messages, the
pgsql-committers archive do not seem a very useful resource anymore.
The Git "shortlog" seems much better, so maybe we should point to that.
I missed why that happened in the first place, but based on being a
subscriber isn't that something that should be split onto another list
regardless?
IIRC, it was essentially a political decision, meant to help make
pgfoundry authors feel more like a part of the core project. Personally
I filter the non-core commits separately anyway...
regards, tom lane