MarcFournierTomLaneThomasLockhartDavidFetter1999-05-20The CVS Repository
The PostgreSQL source code is stored and managed using the
CVS version control system.
At least three methods, anonymous CVS, rsync,
and CVSup,
are available to pull the CVS code tree from the
PostgreSQL server to your local machine.
Our Wiki, ,
has additional details on working with CVS.
Getting The Source Via Anonymous CVS
If you would like to keep up with the current sources on a regular
basis, you can fetch them from our CVS server
and then use CVS to
retrieve updates from time to time.
Anonymous CVS
You will need a local copy of CVS
(Concurrent Version Control System), which you can get from
(the official
site with the latest version) or any GNU software archive site
(often somewhat outdated). Many systems have a recent version of
cvs installed by default.
Do an initial login to the CVS server:
cvs -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot login
You will be prompted for a password; you can enter anything except
an empty string.
You should only need to do this once, since the password will be
saved in .cvspass in your home directory.
Fetch the PostgreSQL sources:
cvs -z3 -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot co -P pgsql
This installs the PostgreSQL sources into a
subdirectory pgsql
of the directory you are currently in.
If you have a fast link to the Internet, you might not need
, which instructs
CVS to use gzip compression for transferred data. But
on a modem-speed link, it's a very substantial win.
This initial checkout is a little slower than simply downloading
a tar.gz file; expect it to take 40 minutes or so if you
have a 28.8K modem. The advantage of
CVS
doesn't show up until you want to update the file set later on.
Whenever you want to update to the latest CVS sources,
cd into
the pgsql subdirectory, and issue:
cvs -z3 update -d -P
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.
You can save yourself some typing by making a file .cvsrc
in your home directory that contains:
cvs -z3
update -d -P
This supplies the option to all cvs> commands, and the
and options to cvs update>. Then you just have
to say:
cvs update
to update your files.
CVS can do a lot of other things, such
as fetching prior revisions of the
PostgreSQL sources rather than the
latest development version. For more info consult the manual that
comes with CVS, or see the online
documentation at .
CVS has deficiencies. For example,
generating diffs that add or remove files requires write access to the
CVS repository. To work around that deficiency, use
cvsutils, which is packaged in several
operating systems, and is available in source form at .
Note that building PostgreSQL from a CVS
pull requires reasonably up-to-date versions of bison>
and flex>, which are not needed to build from a distribution
tarball because the files made with them are pre-built in a tarball.
Otherwise the tool requirements are the same as building from source.
CVS Tree OrganizationAuthor
Written by Marc G. Fournier (scrappy@hub.org) on 1998-11-05
The command cvs checkout has a flag, ,
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:
cvs checkout -r REL6_4 tc
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.
You can also check out a module as it was at any given date using the
option.
When you tag more than one file with the same tag you can think
about the tag as a curve drawn through a matrix of file name vs.
revision number. Say we have 5 files with the following revisions:
file1 file2 file3 file4 file5
1.1 1.1 1.1 1.1 /--1.1* <-*- 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
then the tag TAG will reference
file1-1.2, file2-1.3, etc.
For creating a release branch, other than a
-b> option added to the command, it's the same thing.
So, to create the 6.4 release
I did the following:
cd pgsql
cvs tag -b REL6_4
which will create the tag and the branch for the RELEASE tree.
For those with CVS 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:
cd RELEASE
cvs checkout -P -r REL6_4 pgsql
cd ../CURRENT
cvs checkout -P pgsql
which results in two directory trees, RELEASE/pgsql and
CURRENT/pgsql. From that point on,
CVS
will keep track of which repository branch is in which directory tree, and will
allow independent updates of either tree.
If you are only working on the CURRENT
source tree, you just do
everything as before we started tagging release branches.
After you've done the initial checkout on a branch:
cvs checkout -r REL6_4
anything you do within that directory structure is restricted to that
branch. If you apply a patch to that directory structure and do a:
cvs commit
while inside of it, the patch is applied to the branch and
only the branch.
Getting The Source Via rsync
An alternative to using anonymous CVS for retrieving the
PostgreSQL source tree is
rsync, an incremental file transfer tool.
A major advantage to using rsync is that it
can reliably replicate the entire CVS repository
on your local system, allowing fast local access to cvs>
operations such as and .
Other advantages include fast synchronization to the
PostgreSQL server due to an efficient
streaming transfer protocol which only sends the changes since the last
update.
You can download the CVS repository using this command:
rsync -avzH --delete anoncvs.postgresql.org::pgsql-cvs cvsroot/
For full instructions, see the "rsync" section in the
pgbuildfarm instructions.
Getting The Source Via CVSup
Another alternative to using anonymous CVS for retrieving
the PostgreSQL source tree
is CVSup.
CVSup was developed by
John Polstra (jdp@polstra.com) to
distribute CVS repositories and other file trees for the
FreeBSD project.
Preparing A CVSup Client System
Two directory areas are required for CVSup
to do its job: a local CVS repository
(or simply a directory area if you are fetching a snapshot rather
than a repository; see below)
and a local CVSup bookkeeping
area. These can coexist in the same directory tree.
Decide where you want to keep your local copy of the
CVS repository. On one of our systems we
recently set up a repository in /home/cvs/,
but had formerly kept it under a
PostgreSQL development tree in
/opt/postgres/cvs/. If you intend to keep your
repository in /home/cvs/, then put:
setenv CVSROOT /home/cvs
in your .cshrc file, or a similar line in
your .bashrc or
.profile file, depending on your shell.
The cvs repository area must be initialized.
Once CVSROOT is set, then this can be done with a
single command:
cvs init
after which you should see at least a directory named
CVSROOT when listing the
CVSROOT directory:
$ ls $CVSROOT
CVSROOT/
Running a CVSup Client
Verify that
cvsup is in your path; on most systems
you can do this by typing:
which cvsup
Then, simply run
cvsup using:
cvsup -L 2 postgres.cvsup
where enables some status messages so you
can monitor the progress of the update,
and postgres.cvsup is
the path and name you have given to your
CVSup configuration file.
Here is a CVSup configuration file
modified for a specific installation, and which maintains a full
local CVS repository:
# This file represents the standard CVSup distribution file
# for the 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
If you specify
The following is a suggested CVSup configuration file from
the PostgreSQL>
ftp site
which will fetch the current snapshot only:
# This file represents the standard CVSup distribution file
# for the 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=/usr/local/pgsql
# prefix directory where CVSup will store the actual distribution(s)
*default prefix=/usr/local/pgsql
# complete distribution, including all below
pgsql
# individual distributions vs 'the whole thing'
# pgsql-doc
# pgsql-perl5
# pgsql-src