diff --git a/LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml b/LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml
index b6f5a709..b0425d3b 100644
--- a/LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml
+++ b/LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml
@@ -72,7 +72,8 @@
 <date>2002-09-10</date>
 <authorinitials>vv</authorinitials>
 <revremark>Added content related to tagging and daily builds. Changed 
-Linuxdoc URLs to tldp</revremark>
+Linuxdoc URLs to tldp.  Fixed stale links and added other corrections
+suggested by readers.</revremark>
 </revision>
 
 <revision>
@@ -152,12 +153,16 @@ verbally as a bunch of <quote>gotchas</quote> on &CVSAB;, it was time to put
 down on paper some of the best practices that will work well for  
 &CVSAB; based projects.  </para>
 
-<note>
-<para>This paper is not an introduction to &CVSAB; and its usage.  There are
+<note> <para>This paper assumes that the reader is familiar with the
+fundamentals of software version control.  Including features like
+branching, merging, tagging (labelling) etc., offered by modern version
+control tools such as  &CVSAB; </para>
+
+<para>Further, This paper is not an introduction to &CVSAB; and its usage.  There are
 excellent articles available on the net for the same.  This paper assumes
 that the reader is familiar with &CVSAB; commands and is looking at
-deploying &CVSAB; in his or her organization.</para>  Some of the popular
-&CVSAB; related links that can provide &CVSAB; education are.
+deploying &CVSAB; in his or her organization.  Some of the popular
+&CVSAB; related links that can provide &CVSAB; education are. </para>
 <orderedlist>
 
 <listitem>
@@ -172,10 +177,6 @@ CVS</emphasis> has GPL'd sections <ulink url="http://cvsbook.red-bean.com">avail
 </para>
 </listitem>
 
-<listitem>
-<para>
-</para>
-</listitem>
 </orderedlist>
 </note>
 <!-- Section2: copyright -->
@@ -257,17 +258,16 @@ major installation and backups at regular intervals.  </para> </sect2>
 <!-- Section2: credits -->
 <sect2 id="credits">
 <title>Credits</title>
-<para>The list of people who have provided inputs and information for this
+<para>The list of people who have provided information and correction for this
 paper in no particular order are.
 <orderedlist>
 
 <listitem> <para>Jens-Uwe Mager </para> </listitem>
-
 <listitem> <para>Jorgen Grahn </para> </listitem>
-
 <listitem> <para>Thomas S. Urban </para> </listitem>
 <listitem> <para>Cam Mayor </para> </listitem>
 <listitem> <para>Sally Miller</para> </listitem>
+<listitem> <para>Niels Jakob Darger</para> </listitem>
 
 </orderedlist>
 </para>
@@ -457,11 +457,11 @@ find the &CVSAB; command-line interface daunting.  The adoption and usage of
 &CVSAB; can be improved by using GUI tools for &CVSAB; clients.  </para>
 
 <para> GUI tools for &CVSAB; are available at <ulink
-url="http://cvsgui.sourceforge.net/"/>http://cvsgui.sourceforge.net/</ulink>.  GUI interfaces
-are available for most of the popular platforms (Windows, Mac and Linux).
-In addition, on the Windows platform there is an <acronym>SCC</acronym>
-extension that allows integration of &CVSAB; as the configuration control
-tool with popular IDE.</para>
+url="http://cvsgui.sourceforge.net/">http://cvsgui.sourceforge.net/</ulink>.
+GUI interfaces are available for most of the popular platforms (Windows, Mac
+and Linux).  In addition, on the Windows platform there is an
+<acronym>SCC</acronym> extension that allows integration of &CVSAB; as the
+configuration control tool with popular IDE.</para>
 
 </sect2>
 
@@ -713,7 +713,7 @@ in time. </para>
 
 <title>&section2-tagrelease;</title> 
 
-<para>After each release, the entire code base must be tagged with an
+<para>As part of the release process,  the entire code base must be tagged with an
 identifier that can help in uniquely identifying the release.  A tag gives a
 label to the collection of revisions represented by one developer's working
 copy (usually, that working copy is completely up to date so the tag name is
@@ -728,6 +728,12 @@ identifier is of the form.  </para>
 	<literal>release_</literal>{major version #}_{minor version #}
 </literallayout>
 
+<note> <para>As one reader pointed out to me, a good practice here is to tag
+the release first. Checkout the entire codebase using the tag, and then
+proceed to go through a build / deploy / test process before making the
+actual release.  This will absolutely ensure that what <quote>leaves the
+door </quote> is a verified and tested codebase.</para> </note>
+
 </sect2>
 
 <sect2 id="section2-branchatrelease" xreflabel="&section2-branchatrelease;">