Postgres server to your local machine.
-
-
<productname>CVS</productname> Tree Organization
-
-
-
Author
-
-
-
-
- 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,
- 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>
+
+
<productname>CVS</productname> Tree Organization
+
+
+
Author
+
+
+
+
+ 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,
+ 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>
projects / postgresql.git / commitdiff