Update FAQ_DEV.

doc/src/FAQ/FAQ_DEV.html

@@ -545,24 +545,23 @@
 
     <H3><A name="15">15</A>) How are RPM's packaged?</H3>
 
-<P>This was written by Lamar Owen:</P>
-<P>
+    <P>This was written by Lamar Owen:</P>
 <PRE>
 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. 
 'How is the RPM built?' is a multifaceted question.  The obvious simple
 answer is that I maintain:
-	1.)	A set of patches to make certain portions of the source
-		tree 'behave' in the different environment of the RPMset;
-	2.)	The initscript;
-	3.)	Any other ancilliary scripts and files;
-	4.)	A README.rpm-dist document that tries to adequately document
-		both the differences between the RPM build and the WHY of the
-		differences, as well as useful RPM environment operations
-		(like, using syslog, upgrading, getting postmaster to
-		start at OS boot, etc);
-	5.)	The spec file that throws it all together.  This is not a 
-		trivial undertaking in a package of this size.
+    1.) A set of patches to make certain portions of the source
+        tree 'behave' in the different environment of the RPMset;
+    2.) The initscript;
+    3.) Any other ancilliary scripts and files;
+    4.) A README.rpm-dist document that tries to adequately document
+        both the differences between the RPM build and the WHY of the
+        differences, as well as useful RPM environment operations
+        (like, using syslog, upgrading, getting postmaster to
+        start at OS boot, etc);
+    5.) The spec file that throws it all together.  This is not a 
+        trivial undertaking in a package of this size.
 
 I then download and build on as many different canonical distributions
 as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 on
@@ -635,24 +634,23 @@ stance. IMHO, of course.
 Of course, there are many projects that DO include all the files
 necessary to build RPMs from their Official Tarball (TM).
 </PRE>
-<P>
 
     <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>
-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.
 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
-&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
 next release.
 
 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
 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:
 
 $ cvs log HISTORY | more
@@ -681,16 +679,16 @@ keyword substitution: kv
 total revisions: 129;   selected revisions: 129
 More---q
 
-Unfortunately &quot;cvs log&quot; isn't all that great about distinguishing
-branches from tags --- it calls 'em all &quot;symbolic names&quot;.  (A &quot;tag&quot; just
+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_0_PATCHES
-	REL6_5_PATCHES
+    REL7_1_STABLE
+    REL7_0_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
@@ -705,25 +703,25 @@ 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.)
 
 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
 
 To get a past branch, you cd to whereever you want it and say
 
-	cvs ... checkout -r BRANCHNAME pgsql
+    cvs ... checkout -r BRANCHNAME pgsql
 
 For example, just a couple days ago I did
 
-	mkdir ~postgres/REL7_1
-	cd ~postgres/REL7_1
-	cvs ... checkout -r REL7_1_STABLE pgsql
+    mkdir ~postgres/REL7_1
+    cd ~postgres/REL7_1
+    cvs ... checkout -r REL7_1_STABLE pgsql
 
 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,
-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.
 Easy as can be.
 
@@ -735,9 +733,8 @@ 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.
 </PRE>
 
-<P>Also, Ian Lance Taylor points out that branches and tags can be
-distiguished by using &quot;cvs status -v&quot;.</P>
-
+    <P>Also, Ian Lance Taylor points out that branches and tags can be
+    distiguished by using "cvs status -v".</P>
   </BODY>
 </HTML>