diff --git a/doc/src/sgml/cvs.sgml b/doc/src/sgml/cvs.sgml index 55b17a23d3..ea18c9b597 100644 --- a/doc/src/sgml/cvs.sgml +++ b/doc/src/sgml/cvs.sgml @@ -1,4 +1,4 @@ - + @@ -23,23 +23,97 @@ 1999-05-20 - The <productname>CVS</productname> Repository + The Source Code Repository The PostgreSQL source code is stored and managed using the - CVS version control system. + CVS version control system. An official mirror using + Git is also available, for those who wish to use a + distributed version control system. This mirror is automatically + updated whenever the main repository changes, so it always contains the latest + versions of all branches. - 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. + Using git is the most flexible way to work with the source, and it + allows you to work offline without having constant access to the project servers. + rsync based cvs also lets you work offline, but + lacks many of the other advantages of git. + + Our Wiki, and + , + has additional details on working with CVS and Git. + + + + Getting The Source Via <productname>Git</> + + + With 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. + + + + Git + + + + You will need an installed version of git, which you can get + from . Many systems also have a recent + version of git installed by default, or available in their + package repository system. + + + + + + To being using the git repository, make a clone of the official mirror: + + +git clone git://git.postgresql.org/git/postgresql.git + + + 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. + + + + 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: + + +git clone http://git.postgresql.org/git/postgresql.git + + + The http protocol is less efficient than the git protocol, so it will be + slightly slower to use. + + + + + + Whenever you want to get the latest updates in the system, cd + into the repository, and run: + + +git fetch + + + + + + 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 + . + + + Getting The Source Via Anonymous <productname>CVS</productname> @@ -92,22 +166,11 @@ 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 + a tar.gz file. The advantage of CVS doesn't show up until you want to update the file set later on. @@ -163,7 +226,8 @@ cvs update CVS repository. To work around that deficiency, use cvsutils, which is packaged in several operating systems, and is available in source form at . + url="http://www.red-bean.com/cvsutils/">, or use git + or another system designed to work offline. @@ -176,124 +240,6 @@ cvs update - - <productname>CVS</productname> Tree Organization - - - - Author - - 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 <productname>rsync</productname> @@ -301,7 +247,8 @@ cvs commit 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 + A major advantage to using rsync instead of + plain cvs is that it can reliably replicate the entire CVS repository on your local system, allowing fast local access to cvs operations such as and . @@ -321,187 +268,4 @@ rsync -avzH --delete anoncvs.postgresql.org::pgsql-cvs cvsroot/ pgbuildfarm instructions. - - - Getting The Source Via <productname>CVSup</productname> - - - 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 <productname>CVSup</productname> 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 <productname>CVSup</productname> 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 - - - - diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 0f9ce3eeee..19848ce6aa 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -1,4 +1,4 @@ - + <![%standalone-include[<productname>PostgreSQL</>]]> @@ -357,6 +357,11 @@ su - postgres Change into that directory for the rest of the installation procedure. </para> + + <para> + You can also get the source directly from the version control repository, see + <xref linkend="cvs">. + </para> </sect1> ]]>