diff --git a/doc/src/sgml/cvs.sgml b/doc/src/sgml/cvs.sgml index d019de89b1..8472895c43 100644 --- a/doc/src/sgml/cvs.sgml +++ b/doc/src/sgml/cvs.sgml @@ -1,5 +1,5 @@ @@ -37,123 +37,6 @@ Thomas Lockhart Postgres server to your local machine. - - <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 1.0 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 filename 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 then 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. - - - - Now, for those with CVS access, it's too simple. - 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 Anonymous <productname>CVS</productname> @@ -286,6 +169,124 @@ $ chmod -R go-w pgsql + + <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 filename 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 then 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>CVSup</productname>