<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.13 2000/12/22 21:51:57 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.14 2001/01/20 04:16:55 momjian Exp $
CVS code repository
Thomas Lockhart
-->
<productname>Postgres</productname> server to your local machine.
</para>
- <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 1.0 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 "a curve drawn through a matrix of filename vs.
- revision number". 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 then a
- -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>
- Now, for those with <productname>CVS</productname> access, it's too simple.
- 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="anoncvs">
<title>Getting The Source Via Anonymous <productname>CVS</productname></title>
</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 "a curve drawn through a matrix of filename vs.
+ revision number". 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 then a
+ -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>
projects / thirdparty / postgresql.git / commitdiff
