Removed references to linuxdoc. Please publish this version

This commit is contained in:
vivekv 2002-12-01 18:29:02 +00:00
parent 80ddef3601
commit c4b660e963
1 changed files with 31 additions and 6 deletions

View File

@ -6,7 +6,7 @@
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
<!-- Document version --> <!-- Document version -->
<!ENTITY DOCVERSION "0.5"> <!ENTITY DOCVERSION "0.6">
<!-- File Includes --> <!-- File Includes -->
<!ENTITY GFDL-FILE SYSTEM "gfdl.xml"> <!ENTITY GFDL-FILE SYSTEM "gfdl.xml">
@ -67,6 +67,14 @@
<revhistory> <revhistory>
<revision>
<revnumber>0.6</revnumber>
<date>2002-09-10</date>
<authorinitials>vv</authorinitials>
<revremark>Added content related to tagging and daily builds. Changed
Linuxdoc URLs to tldp</revremark>
</revision>
<revision> <revision>
<revnumber>0.5</revnumber> <revnumber>0.5</revnumber>
<date>2002-08-25</date> <date>2002-08-25</date>
@ -449,7 +457,7 @@ find the &CVSAB; command-line interface daunting. The adoption and usage of
&CVSAB; can be improved by using GUI tools for &CVSAB; clients. </para> &CVSAB; can be improved by using GUI tools for &CVSAB; clients. </para>
<para> GUI tools for &CVSAB; are available at <ulink <para> GUI tools for &CVSAB; are available at <ulink
url="http://www.cvsgui.org">http://www.cvsgui.org</ulink>. GUI interfaces url="http://cvsgui.sourceforge.net/"/>http://cvsgui.sourceforge.net/</ulink>. GUI interfaces
are available for most of the popular platforms (Windows, Mac and Linux). are available for most of the popular platforms (Windows, Mac and Linux).
In addition, on the Windows platform there is an <acronym>SCC</acronym> In addition, on the Windows platform there is an <acronym>SCC</acronym>
extension that allows integration of &CVSAB; as the configuration control extension that allows integration of &CVSAB; as the configuration control
@ -843,6 +851,10 @@ The project team should ensure that successful builds are top priority on
their agenda. The seriousness can be emphasised by setting up a penalty for their agenda. The seriousness can be emphasised by setting up a penalty for
breaking the build. </para> breaking the build. </para>
<para>Each build can be tagged in CVS using a standard naming convention.
This can help developers checkout a working version of the entire system
from daily builds for local development. </para>
</sect2> </sect2>
<sect2 id="section2-automate" xreflabel="&section2-automate;"> <sect2 id="section2-automate" xreflabel="&section2-automate;">
@ -1024,6 +1036,7 @@ The bug fix team will check out using the command line
</listitem> </listitem>
</orderedlist> </orderedlist>
<para> As soon as the bug fix team completes the two top priority bugs, they <para> As soon as the bug fix team completes the two top priority bugs, they
will update, verify a successful build and commit their changes to the bug will update, verify a successful build and commit their changes to the bug
fix branch using the command line fix branch using the command line
@ -1040,10 +1053,22 @@ the branch should be committed back into the repository. </para>
cvs commit -R -r release_1_0_patches {module name} cvs commit -R -r release_1_0_patches {module name}
</command> </command>
<para>Now, the regular process of build-test-build is followed to make a <para><xref linkend="section2-bebo" /> : On a daily basis, each developer
version ready for delivery. The final version of the source code is will check in code to &CVSAB; and to ensure sanity of code, daily builds on
committed into &CVSAB;. Now, two practices have to be followed. the bug fixed branch will be undertaken by checking out from
</para> &CVSAB; on a clean environment and completely rebuilt. These daily builds
can be tagged in &CVSAB; using the following naming convention </para>
<literallayout>
<literal>build_1_1_yyyymmdd : for the branch</literal>
<literal>build_2_0_yyyymmdd : for the trunk</literal>
</literallayout>
<para>The regular process of build-test-fix is followed to make a version
ready for delivery. The tag will help developers checkout a working copy of
the latest build as and when necessary. </para>
<para> When the source code is released to the outside world, two practices
have to be followed. </para>
<orderedlist> <orderedlist>
<listitem> <listitem>