database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-03 22:24:49 +03:00
Code

Remove anonymous cvs instructions, and replace them with instructions

Browse Source 
for git. Change other references from cvs to git as well.
This commit is contained in:
Magnus Hagander 2010-09-22 20:10:39 +02:00
parent 1f2378b1ea
commit adbe80f7ae
7 changed files with 102 additions and 476 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

465
doc/src/sgml/cvs.sgml
View File

@ -1,465 +0,0 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.39 2006/11/17 05:29:46 neilc Exp $ -->
<appendix id="cvs">
<appendixinfo>
<authorgroup>
<author>
<firstname>Marc</firstname>
<surname>Fournier</surname>
</author>
<author>
<firstname>Tom</firstname>
<surname>Lane</surname>
</author>
<author>
<firstname>Thomas</firstname>
<surname>Lockhart</surname>
</author>
</authorgroup>
<date>1999-05-20</date>
</appendixinfo>
<title>The <productname>CVS</productname> Repository</title>
<para>
The <productname>PostgreSQL</productname> source code is stored and managed using the
<productname>CVS</productname> version control system.
</para>
<para>
At least two methods,
anonymous CVS and <productname>CVSup</productname>,
are available to pull the <productname>CVS</productname> code tree from the
<productname>PostgreSQL</productname> server to your local machine.
</para>
<sect1 id="anoncvs">
<title>Getting The Source Via Anonymous <productname>CVS</productname></title>
<para>
If you would like to keep up with the current sources on a regular
basis, you can fetch them from our <productname>CVS</productname> server
and then use <productname>CVS</productname> to
retrieve updates from time to time.
</para>
<procedure>
<title>Anonymous CVS</title>
<step>
<para>
You will need a local copy of <productname>CVS</productname>
(Concurrent Version Control System), which you can get from
<ulink url="http://www.nongnu.org/cvs/"></ulink> (the official
site with the latest version) or any GNU software archive site
(often somewhat outdated). Many systems have a recent version of
<application>cvs</application> installed by default.
</para>
</step>
<step>
<para>
Do an initial login to the <productname>CVS</productname> server:
<programlisting>
cvs -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot login
</programlisting>
You will be prompted for a password; you can enter anything except
an empty string.
</para>
<para>
You should only need to do this once, since the password will be
saved in <filename>.cvspass</filename> in your home directory.
</para>
</step>
<step>
<para>
Fetch the <productname>PostgreSQL</productname> sources:
<programlisting>
cvs -z3 -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot co -P pgsql
</programlisting>
This installs the <productname>PostgreSQL</productname> sources into a
subdirectory <filename>pgsql</filename>
of the directory you are currently in.
<note>
<para>
If you have a fast link to the Internet, you may not need
<option>-z3</option>, which instructs
<productname>CVS</productname> to use <command>gzip</command> compression for transferred data. But
on a modem-speed link, it's a very substantial win.
</para>
</note>
</para>
<para>
This initial checkout is a little slower than simply downloading
a <filename>tar.gz</filename> file; expect it to take 40 minutes or so if you
have a 28.8K modem. The advantage of
<productname>CVS</productname>
doesn't show up until you want to update the file set later on.
</para>
</step>
<step>
<para>
Whenever you want to update to the latest <productname>CVS</productname> sources,
<command>cd</command> into
the <filename>pgsql</filename> subdirectory, and issue
<programlisting>
cvs -z3 update -d -P
</programlisting>
This will fetch only the changes since the last time you updated.
You can update in just a couple of minutes, typically, even over
a modem-speed line.
</para>
</step>
<step>
<para>
You can save yourself some typing by making a file <filename>.cvsrc</filename>
in your home directory that contains
<programlisting>
cvs -z3
update -d -P
</programlisting>
This supplies the <option>-z3</option> option to all <command>cvs</> commands, and the
<option>-d</option> and <option>-P</option> options to <command>cvs update</>. Then you just have
to say
<programlisting>
cvs update
</programlisting>
to update your files.
</para>
</step>
</procedure>
<para>
<productname>CVS</productname> can do a lot of other things, such
as fetching prior revisions of the
<productname>PostgreSQL</productname> sources rather than the
latest development version. For more info consult the manual that
comes with <productname>CVS</productname>, or see the online
documentation at <ulink url="http://www.nongnu.org/cvs/"></ulink>.
</para>
</sect1>
<sect1 id="cvs-tree">
<title><productname>CVS</productname> Tree Organization</title>
<para>
<note>
<title>Author</title>
<para>
Written by Marc G. Fournier (<email>scrappy@hub.org</email>) on 1998-11-05
</para>
</note>
</para>
<para>
The command <command>cvs checkout</command> has a flag, <option>-r</option>,
that lets you check out a
certain revision of a module. This flag makes it easy to, for example,
retrieve the
sources that make up release 6_4 of the module `tc' at any time in the
future:
<programlisting>
cvs checkout -r REL6_4 tc
</programlisting>
This is useful, for instance, if someone claims that there is a bug in
that release, but you cannot find the bug in the current working copy.
<tip>
<para>
You can also check out a module as it was at any given date using the
<option>-D</option> option.
</para>
</tip>
</para>
<para>
When you tag more than one file with the same tag you can think
about the tag as <quote>a curve drawn through a matrix of file name vs.
revision number</quote>. Say we have 5 files with the following revisions:
<programlisting>
file1 file2 file3 file4 file5
1.1 1.1 1.1 1.1 /--1.1* &lt;-*- TAG
1.2*- 1.2 1.2 -1.2*-
1.3 \- 1.3*- 1.3 / 1.3
1.4 \ 1.4 / 1.4
\-1.5*- 1.5
1.6
</programlisting>
then the tag <literal>TAG</literal> will reference
file1-1.2, file2-1.3, etc.
<note>
<para>
For creating a release branch, other than a
<literal>-b</> option added to the command, it's the same thing.</para>
</note>
</para>
<para>
So, to create the 6.4 release
I did the following:
<programlisting>
cd pgsql
cvs tag -b REL6_4
</programlisting>
which will create the tag and the branch for the RELEASE tree.
</para>
<para>
For those with <productname>CVS</productname> access, it's simple to
create directories for different versions.
First, create two subdirectories, RELEASE and CURRENT, so that you don't
mix up the two. Then do:
<programlisting>
cd RELEASE
cvs checkout -P -r REL6_4 pgsql
cd ../CURRENT
cvs checkout -P pgsql
</programlisting>
which results in two directory trees, <filename>RELEASE/pgsql</filename> and
<filename>CURRENT/pgsql</filename>. From that point on,
<productname>CVS</productname>
will keep track of which repository branch is in which directory tree, and will
allow independent updates of either tree.
</para>
<para>
If you are <emphasis>only</emphasis> working on the <literal>CURRENT</literal>
source tree, you just do
everything as before we started tagging release branches.
</para>
<para>
After you've done the initial checkout on a branch
<programlisting>
cvs checkout -r REL6_4
</programlisting>
anything you do within that directory structure is restricted to that
branch. If you apply a patch to that directory structure and do a
<programlisting>
cvs commit
</programlisting>
while inside of it, the patch is applied to the branch and
<emphasis>only</emphasis> the branch.
</para>
</sect1>
<sect1 id="cvsup">
<title>Getting The Source Via <productname>CVSup</productname></title>
<para>
An alternative to using anonymous CVS for retrieving
the <productname>PostgreSQL</productname> source tree
is <productname>CVSup</productname>.
<productname>CVSup</productname> was developed by
John Polstra (<email>jdp@polstra.com</email>) to
distribute CVS repositories and other file trees for the
<ulink url="http://www.freebsd.org">FreeBSD project</ulink>.
</para>
<para>
A major advantage to using
<productname>CVSup</productname> is that it can reliably
replicate the <emphasis>entire</emphasis> CVS repository on your local system,
allowing fast local access to <command>cvs</> operations such as <option>log</option>
and <option>diff</option>. Other advantages include fast synchronization to
the <productname>PostgreSQL</productname> server due to an efficient
streaming transfer protocol which only sends the changes since the last update.
</para>
<sect2>
<title>Preparing A <productname>CVSup</productname> Client System</title>
<para>
Two directory areas are required for <productname>CVSup</productname>
to do its job: a local <productname>CVS</productname> repository
(or simply a directory area if you are fetching a snapshot rather
than a repository; see below)
and a local <productname>CVSup</productname> bookkeeping
area. These can coexist in the same directory tree.
</para>
<para>
Decide where you want to keep your local copy of the
<productname>CVS</productname> repository. On one of our systems we
recently set up a repository in <filename>/home/cvs/</filename>,
but had formerly kept it under a
<productname>PostgreSQL</productname> development tree in
<filename>/opt/postgres/cvs/</filename>. If you intend to keep your
repository in <filename>/home/cvs/</filename>, then put
<programlisting>
setenv CVSROOT /home/cvs
</programlisting>
in your <filename>.cshrc</filename> file, or a similar line in
your <filename>.bashrc</filename> or
<filename>.profile</filename> file, depending on your shell.
</para>
<para>
The <application>cvs</application> repository area must be initialized.
Once <envar>CVSROOT</envar> is set, then this can be done with a
single command:
<programlisting>
cvs init
</programlisting>
after which you should see at least a directory named
<filename>CVSROOT</filename> when listing the
<envar>CVSROOT</envar> directory:
<programlisting>
$ ls $CVSROOT
CVSROOT/
</programlisting>
</para>
</sect2>
<sect2>
<title>Running a <productname>CVSup</productname> Client</title>
<para>
Verify that
<application>cvsup</application> is in your path; on most systems
you can do this by typing
<programlisting>
which cvsup
</programlisting>
Then, simply run
<application>cvsup</application> using:
<programlisting>
cvsup -L 2 <replaceable class="parameter">postgres.cvsup</replaceable>
</programlisting>
where <option>-L 2</option> enables some status messages so you
can monitor the progress of the update,
and <replaceable class="parameter">postgres.cvsup</replaceable> is
the path and name you have given to your
<productname>CVSup</productname> configuration file.
</para>
<para>
Here is a <productname>CVSup</productname> configuration file
modified for a specific installation, and which maintains a full
local <productname>CVS</productname> repository:
<programlisting>
# This file represents the standard CVSup distribution file
# for the <productname>PostgreSQL</> ORDBMS project
# Modified by lockhart@fourpalms.org 1997-08-28
# - Point to my local snapshot source tree
# - Pull the full CVS repository, not just the latest snapshot
#
# Defaults that apply to all the collections
*default host=cvsup.postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
# enable the following line to get the latest snapshot
#*default tag=.
# enable the following line to get whatever was specified above or by default
# at the date specified below
#*default date=97.08.29.00.00.00
# base directory where CVSup will store its 'bookmarks' file(s)
# will create subdirectory sup/
#*default base=/opt/postgres # /usr/local/pgsql
*default base=/home/cvs
# prefix directory where CVSup will store the actual distribution(s)
*default prefix=/home/cvs
# complete distribution, including all below
pgsql
# individual distributions vs 'the whole thing'
# pgsql-doc
# pgsql-perl5
# pgsql-src
</programlisting>
</para>
<para>
If you specify <option>repository</> instead of <option>pgsql</>
in the above setup, you will get a complete copy of the entire
repository at cvsup.postgresql.org, including its
<filename>CVSROOT</filename> directory. If you do that, you will
probably want to exclude those files in that directory that you
want to modify locally, using a refuse file. For example, for the
above setup you might put this in
<filename>/home/cvs/sup/repository/refuse</>:
<programlisting>
CVSROOT/config*
CVSROOT/commitinfo*
CVSROOT/loginfo*
</programlisting>
See the <productname>CVSup</> manual pages for how to use refuse files.
</para>
<para>
The following is a suggested <productname>CVSup</productname> configuration file from
the <productname>PostgreSQL</>
<ulink url="ftp://ftp.postgresql.org/pub/CVSup/README.cvsup">
ftp site</ulink>
which will fetch the current snapshot only:
<programlisting>
# This file represents the standard CVSup distribution file
# for the <productname>PostgreSQL</> ORDBMS project
#
# Defaults that apply to all the collections
*default host=cvsup.postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
*default tag=.
# base directory where CVSup will store its 'bookmarks' file(s)
*default base=<replaceable class="parameter">/usr/local/pgsql</replaceable>
# prefix directory where CVSup will store the actual distribution(s)
*default prefix=<replaceable class="parameter">/usr/local/pgsql</replaceable>
# complete distribution, including all below
pgsql
# individual distributions vs 'the whole thing'
# pgsql-doc
# pgsql-perl5
# pgsql-src
</programlisting>
</para>
</sect2>
</sect1>
</appendix>

2
doc/src/sgml/filelist.sgml
View File

@ -90,12 +90,12 @@
<!-- appendixes -->
<!entity contacts SYSTEM "contacts.sgml">
<!entity cvs SYSTEM "cvs.sgml">
<!entity datetime SYSTEM "datetime.sgml">
<!entity docguide SYSTEM "docguide.sgml">
<!entity errcodes SYSTEM "errcodes.sgml">
<!entity features SYSTEM "features.sgml">
<!entity keywords SYSTEM "keywords.sgml">
<!entity sourcerepo SYSTEM "sourcerepo.sgml">
<!entity release SYSTEM "release.sgml">
<!entity release-8.2 SYSTEM "release-8.2.sgml">

6
doc/src/sgml/installation.sgml
View File

@ -292,8 +292,8 @@ su - postgres
</para>
<para>
If you are building from a <acronym>CVS</acronym> tree instead of
using a released source package, or if you want to do development,
If you are building from a <productname>Git</productname> tree instead of
using a released source package, or if you want to do server development,
you also need the following packages:
<itemizedlist>
@ -310,7 +310,7 @@ su - postgres
</indexterm>
GNU <application>Flex</> and <application>Bison</>
are needed to build a CVS checkout or if you changed the actual
are needed to build from a Git checkout, or if you changed the actual
scanner and parser definition files. If you need them, be sure
to get <application>Flex</> 2.5.4 or later and
<application>Bison</> 1.875 or later. Other <application>yacc</>

2
doc/src/sgml/postgres.sgml
View File

@ -252,7 +252,7 @@
&keywords;
&features;
&release;
&cvs;
&sourcerepo;
&docguide;
&external-projects;

4
doc/src/sgml/problems.sgml
View File

@ -228,8 +228,8 @@
If the function or the options do not exist then your version is
more than old enough to warrant an upgrade.
If you run a prepackaged version, such as RPMs, say so, including any
subversion the package may have. If you are talking about a CVS
snapshot, mention that, including its date and time.
subversion the package might have. If you are talking about a Git
snapshot, mention that, including the commit hash.
</para>
<para>

6
doc/src/sgml/release.sgml
View File

@ -47,14 +47,12 @@ can be created without links to the main documentation.
<para>
A complete list of changes for each release can be obtained by
viewing the <link linkend="cvs">CVS</link> logs for each release.
viewing the <link linkend="git">Git</link> logs for each release.
The <ulink
url="http://archives.postgresql.org/pgsql-committers/">pgsql-committers
email list</ulink> records all source code changes as well. There is also
a <ulink url="http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/">web
a <ulink url="http://git.postgresql.org/gitweb?p=postgresql.git;a=summary">web
interface</ulink> that shows changes to specific files.
<!-- we need a file containing the CVS logs for each release, and something
like the SVN web interface that groups commits but has branches -->
</para>
<para>

93
doc/src/sgml/sourcerepo.sgml Normal file
View File

@ -0,0 +1,93 @@
<!-- doc/src/sgml/sourcerepo.sgml -->
<appendix id="sourcerepo">
<title>The Source Code Repository</title>
<para>
The <productname>PostgreSQL</productname> source code is stored and managed using the
<productname>Git</productname> version control system. An public mirror of this
is available and updated within a minute of the master repository.
</para>
<para>
Our wiki, <ulink
url="http://wiki.postgresql.org/wiki/Working_with_Git"></ulink>,
has additional details on working with Git.
</para>
<para>
Note that building <productname>PostgreSQL</productname> from the source
repository requires reasonably up-to-date versions of <application>bison</>
and <application>flex</>. These tools are not needed to build from a
distribution tarball since their output is included in the file.
You will need Perl as well, but otherwise the tool requirements are the
same.
</para>
<sect1 id="git">
<title>Getting The Source Via <productname>Git</></title>
<para>
With <productname>Git</> you will make a copy of the entire code repository
to your local machine, so you will have access to all history and branches
offline. This is the fastest and most flexible way to develop or test
patches.
</para>
<procedure>
<title>Git</title>
<step>
<para>
You will need an installed version of <productname>Git</>, which you can get
from <ulink url="http://git-scm.com"></ulink>. Many systems also have a recent
version of <application>Git</> installed by default, or available in their
package repository system.
</para>
</step>
<step>
<para>
To being using the Git repository, make a clone of the official mirror:
<programlisting>
git clone git://git.postgresql.org/git/postgresql.git
</programlisting>
This will copy the full repository to your local machine, so it may take
a while to complete, especially if you have a slow Internet connection.
</para>
<para>
The Git mirror can also be reached via the HTTP protocol in case for example
a firewall is blocking access to the Git protocol. Just replace the URL
like:
<programlisting>
git clone http://git.postgresql.org/git/postgresql.git
</programlisting>
The HTTP protocol is less efficient than the Git protocol, so it will be
slower to use.
</para>
</step>
<step>
<para>
Whenever you want to get the latest updates in the system, <command>cd</>
into the repository, and run:
<programlisting>
git fetch
</programlisting>
</para>
</step>
</procedure>
<para>
<productname>Git</> can do a lot more things than just fetch the source. For
more information, consult the man pages for the product, or the website at
<ulink url="http://git-scm.com"></>.
</para>
</sect1>
</appendix>