rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Move anoncvs to top of docs, then put cvs tree. Hope that is OK. Seems 

more logical.
This commit is contained in:
Bruce Momjian 2001-01-20 04:16:55 +00:00
parent 19cba0cc1b
commit 923513b52f
1 changed files with 119 additions and 118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,5 +1,5 @@
<!--
$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
-->
@ -37,123 +37,6 @@ 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>
@ -286,6 +169,124 @@ $ chmod -R go-w pgsql
</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>