mirrors
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update FAQ_DEV.

This commit is contained in:
Bruce Momjian 2001-11-27 20:45:27 +00:00
parent 4343f574eb
commit 2ebb03c9ef
1 changed files with 4 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
doc/src/FAQ/FAQ_DEV.html
View File

@ -12,7 +12,7 @@
<H1>Developer's Frequently Asked Questions (FAQ) for <H1>Developer's Frequently Asked Questions (FAQ) for
PostgreSQL</H1> PostgreSQL</H1>
<P>Last updated: Mon Nov 26 21:48:19 EST 2001</P> <P>Last updated: Tue Nov 27 15:45:22 EST 2001</P>
<P>Current maintainer: Bruce Momjian (<A href= <P>Current maintainer: Bruce Momjian (<A href=
@ -651,51 +651,13 @@ for a stable release just before starting the development cycle for the
next release. next release.
The first thing you have to know is the branch name for the branch you The first thing you have to know is the branch name for the branch you
are interested in getting at. Unfortunately Marc has been less than are interested in getting at. Ian Lance Taylor points out that branches
100% consistent in naming the things. One way to check is to apply and tags can be distiguished by using "cvs status -v". Typical branch
"cvs log" to any file that goes back a long time, for example HISTORY names are:
in the top directory:
$ cvs log HISTORY | more
RCS file: /home/projects/pgsql/cvsroot/pgsql/HISTORY,v
Working file: HISTORY
head: 1.106
branch:
locks: strict
access list:
symbolic names:
REL7_1_STABLE: 1.106.0.2
REL7_1_BETA: 1.79
REL7_1_BETA3: 1.86
REL7_1_BETA2: 1.86
REL7_1: 1.102
REL7_0_PATCHES: 1.70.0.2
REL7_0: 1.70
REL6_5_PATCHES: 1.52.0.2
REL6_5: 1.52
REL6_4: 1.44.0.2
release-6-3: 1.33
SUPPORT: 1.1.1.1
PG95-DIST: 1.1.1
keyword substitution: kv
total revisions: 129; selected revisions: 129
More---q
Unfortunately "cvs log" isn't all that great about distinguishing
branches from tags --- it calls 'em all "symbolic names". (A "tag" just
marks a specific timepoint across all files --- it's essentially a
snapshot whereas a branch is a changeable fileset.) Rule of thumb is
that names attached to four-number versions where the third number is
zero represent branches, the others are just tags. Here we can see that
the extant branches are
REL7_1_STABLE REL7_1_STABLE
REL7_0_PATCHES REL7_0_PATCHES
REL6_5_PATCHES REL6_5_PATCHES
The next commit to the head will be revision 1.107, whereas any changes
committed into the REL7_1_STABLE branch will have revision numbers like
1.106.2.*, corresponding to the branch number 1.106.0.2 (don't ask where
the zero went...).
OK, so how do you do work on a branch? By far the best way is to create OK, so how do you do work on a branch? By far the best way is to create
a separate checkout tree for the branch and do your work in that. Not a separate checkout tree for the branch and do your work in that. Not
@ -736,9 +698,6 @@ the tree right away after a major release --- we wait for a dot-release
or two, so that we won't have to double-patch the first wave of fixes. or two, so that we won't have to double-patch the first wave of fixes.
</PRE> </PRE>
<P>Also, Ian Lance Taylor points out that branches and tags can be
distiguished by using "cvs status -v".</P>
<H3><A name="17">17</A>) How go I get involved in PostgreSQL <H3><A name="17">17</A>) How go I get involved in PostgreSQL
development?</H3> development?</H3>
<P>This was written by Lamar Owen:</P> <P>This was written by Lamar Owen:</P>