diff --git a/LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml b/LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml
index 0f8b10b8..28cd9a1e 100644
--- a/LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml
+++ b/LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml
@@ -125,10 +125,11 @@ some minor fixes</revremark></revision>
 </articleinfo>
 
 <abstract>
+<para>
 <indexterm>
 <primary>CVS Best Practices</primary>
 </indexterm>
-<para>This article explores some of the best practices that can be adopted
+This article explores some of the best practices that can be adopted
 while using CVS as the configuration management tool in your software
 projects.
 </para>
@@ -1072,17 +1073,22 @@ The bug fix team will check out using the command line
 will update, verify a successful build and commit their changes to the bug
 fix branch using the command line
 </para>
+<para>
 <command>
 cvs update -R -r release_1_0_patches {module name}
 </command>
+</para>
 
 <para>The team should perform a build at this point to verify that the
 update did not break any code on the branch.  Once the build is successful,
-the branch should be committed back into the repository.  </para>
+the branch should be committed back into the repository.
+</para>
 
+<para>
 <command>
 cvs commit -R -r release_1_0_patches {module name}
 </command>
+</para>
 
 <para><xref linkend="section2-bebo" /> : On a daily basis, each developer
 will check in code to &CVSAB; and to ensure sanity of code, daily builds on