diff options
Diffstat (limited to 'doc/src/sgml/cvs.sgml')
| -rw-r--r-- | doc/src/sgml/cvs.sgml | 465 |
1 files changed, 0 insertions, 465 deletions
diff --git a/doc/src/sgml/cvs.sgml b/doc/src/sgml/cvs.sgml deleted file mode 100644 index 254bc1e7ff3..00000000000 --- a/doc/src/sgml/cvs.sgml +++ /dev/null @@ -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* <-*- 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> |