database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-05 07:41:25 +03:00
Code Activity

Update FAQ_DEV.

Browse Source
This commit is contained in:
Bruce Momjian
2001-11-27 02:03:05 +00:00
parent f0074b6098
commit 2429c32722
1 changed files with 32 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -546,7 +546,6 @@
<H3><A name="15">15</A>) How are RPM's packaged?</H3> <H3><A name="15">15</A>) How are RPM's packaged?</H3>
<P>This was written by Lamar Owen:</P> <P>This was written by Lamar Owen:</P>
<P>
<PRE> <PRE>
As to how the RPMs are built -- to answer that question sanely requires As to how the RPMs are built -- to answer that question sanely requires
me to know how much experience you have with the whole RPM paradigm. me to know how much experience you have with the whole RPM paradigm.
@@ -635,24 +634,23 @@ stance. IMHO, of course.
Of course, there are many projects that DO include all the files Of course, there are many projects that DO include all the files
necessary to build RPMs from their Official Tarball (TM). necessary to build RPMs from their Official Tarball (TM).
</PRE> </PRE>
<P>
<H3><A name="16">16</A>) How are CVS branches managed?</H3> <H3><A name="16">16</A>) How are CVS branches managed?</H3>
<P>This was written by Tom Lane:
<P> <P>This was written by Tom Lane:</P>
<PRE> <PRE>
If you just do basic &quot;cvs checkout&quot;, &quot;cvs update&quot;, &quot;cvs commit&quot;, then If you just do basic "cvs checkout", "cvs update", "cvs commit", then
you'll always be dealing with the HEAD version of the files in CVS. you'll always be dealing with the HEAD version of the files in CVS.
That's what you want for development, but if you need to patch past That's what you want for development, but if you need to patch past
stable releases then you have to be able to access and update the stable releases then you have to be able to access and update the
&quot;branch&quot; portions of our CVS repository. We normally fork off a branch "branch" portions of our CVS repository. We normally fork off a branch
for a stable release just before starting the development cycle for the 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. Unfortunately Marc has been less than
100% consistent in naming the things. One way to check is to apply 100% consistent in naming the things. One way to check is to apply
&quot;cvs log&quot; to any file that goes back a long time, for example HISTORY "cvs log" to any file that goes back a long time, for example HISTORY
in the top directory: in the top directory:
$ cvs log HISTORY | more $ cvs log HISTORY | more
@@ -681,8 +679,8 @@ keyword substitution: kv
total revisions: 129; selected revisions: 129 total revisions: 129; selected revisions: 129
More---q More---q
Unfortunately &quot;cvs log&quot; isn't all that great about distinguishing Unfortunately "cvs log" isn't all that great about distinguishing
branches from tags --- it calls 'em all &quot;symbolic names&quot;. (A &quot;tag&quot; just branches from tags --- it calls 'em all "symbolic names". (A "tag" just
marks a specific timepoint across all files --- it's essentially a marks a specific timepoint across all files --- it's essentially a
snapshot whereas a branch is a changeable fileset.) Rule of thumb is snapshot whereas a branch is a changeable fileset.) Rule of thumb is
that names attached to four-number versions where the third number is that names attached to four-number versions where the third number is
@@ -705,7 +703,7 @@ with very little beta testing --- so whenever you commit an update to a
stable branch, you'd better be doubly sure that it's correct.) stable branch, you'd better be doubly sure that it's correct.)
Normally, to checkout the head branch, you just cd to the place you Normally, to checkout the head branch, you just cd to the place you
want to contain the toplevel &quot;pgsql&quot; directory and say want to contain the toplevel "pgsql" directory and say
cvs ... checkout pgsql cvs ... checkout pgsql
@@ -721,9 +719,9 @@ For example, just a couple days ago I did
and now I have a maintenance copy of 7.1.*. and now I have a maintenance copy of 7.1.*.
When you've done a checkout in this way, the branch name is &quot;sticky&quot;: When you've done a checkout in this way, the branch name is "sticky":
CVS automatically knows that this directory tree is for the branch, CVS automatically knows that this directory tree is for the branch,
and whenever you do &quot;cvs update&quot; or &quot;cvs commit&quot; in this tree, you'll and whenever you do "cvs update" or "cvs commit" in this tree, you'll
fetch or store the latest version in the branch, not the head version. fetch or store the latest version in the branch, not the head version.
Easy as can be. Easy as can be.
@@ -736,8 +734,7 @@ 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 <P>Also, Ian Lance Taylor points out that branches and tags can be
distiguished by using &quot;cvs status -v&quot;.</P> distiguished by using "cvs status -v".</P>
</BODY> </BODY>
</HTML> </HTML>