LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

Fixed some dead links. Please publish this version

This commit is contained in:
vivekv 2003-06-12 18:16:43 +00:00
parent 744a673068
commit f529033f11
1 changed files with 24 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
LDP/ref/docbook/CVS-BestPractices/cvs-bestpractices.xml
View File

@ -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;">