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

An intermediate version. Some cleanup is still required. Please dont publish this version.

This commit is contained in:
vivekv 2002-03-26 23:58:19 +00:00
parent 777755de4c
commit 35b8b54be2
1 changed files with 67 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -67,7 +67,7 @@
<revision>
<revnumber>0.4</revnumber>
<date></date>
<date>2002-03-10</date>
<authorinitials>vv</authorinitials>
<revremark>Added new email address, Added an example flow to show how the
practices help</revremark>
@ -222,14 +222,13 @@ major installation and backups at regular intervals. </para> </sect2>
<para>The list of people who have provided inputs and information for this
paper in no particular order are.
<orderedlist>
<listitem>
<para>Jens-Uwe Mager
</para>
</listitem>
<listitem>
<para>Jorgen Grahn
</para>
</listitem>
<listitem> <para>Jens-Uwe Mager </para> </listitem>
<listitem> <para>Jorgen Grahn </para> </listitem>
<listitem> <para>Thomas S. Urban </para> </listitem>
</orderedlist>
</para>
</sect2>
@ -555,11 +554,37 @@ configuration.
</para>
<sect2 id="section2-scripting" xreflabel="&section2-scripting;">
<title>&section2-scripting;</title>
<title>&section2-scripting;</title>
<para>Server side scripting refers to the ability to make &CVSAB; server
execute certain scripts when an event occurs. I am currently not aware of any
best practices in this area. Suggestions are welcome.
</para>
execute certain scripts when an event occurs. A common script that
helps is to verify that all cvs commits contain acomment entered by the
developer. The process involves setting up the
<filename>CVSROOT/verifymsg</filename> file to run a script when a file is
checked-in. </para>
<programlisting>
------CVSROOT/verifymsg---------
#Set the verifymsg file to fire a script
DEFAULT /usr/local/bin/validate-cvs-log.sh
------/usr/local/bin/validate-cvs-log.sh ---------
#!/bin/sh
#
# validate-cvs-log.sh logfile
# test that log message has some characters in it
if [ `cat $1 | wc -c ` -lt 10 ] ; then
echo "log message too short; please enter a description for the changes"
exit 1
else
exit 0
fi
</programlisting>
</sect2>
<sect2 id="section2-notification" xreflabel="&section2-notification;">
@ -904,11 +929,14 @@ the system have started to use it full-time and bug reports of various
levels have started to come in. </para>
<para> Before jumping into new enhancements or bug fixes, the best practices
for <xref linkend="section1-branchmerge"/> should be adhered to. Especially
important now is the <xref linkend="section2-tagrelease"/> and
<xref linkend="section2-branchatrelease"/> practices. By doing so, you have
effectively established two <quote>development environments</quote>, one
for future development and the other for bug fixes and minor enhancements on the last release.</para>
for <xref linkend="section1-branchmerge"/> should be followed. Few of
the important practices are <xref linkend="section2-tagrelease"/> and
<xref linkend="section2-branchatrelease"/>. These practices will
effectively established two <quote>development environments</quote>,
one for regular enhancements and the other for bug fixes and minor
enhancements on the last release.</para>
<para>Let us assume that the release was tagged as
<literallayout>
<literal>release_1_0</literal>
@ -926,16 +954,25 @@ for future development and the other for bug fixes and minor enhancements on the
<para>Now, we are ready for business. Let us examine the bug fixes and
enhancements track. Assume that there are three bugs of which two are of a
high priority that needs to go right away (possibly within a week) and the
third can be delivered after some time (say after 4 weeks). Also in the
middle of this schedule we have a regular release scheduled in three weeks.
high priority that should be fixed away (possibly within a week) and the
third can be delivered after some time (say after 4 weeks). In the
middle of this schedule there is a regular release scheduled in three weeks.
Considering that we have a busy month ahead, let us see how exactly we can
use the Best practices to ease the days ahead.</para>
<para>Thus we have two teams, one working on the bug fix branch and another
team working on the features for the next release on the main trunk. These
teams must make sure that they start out with the right version in their
sandbox. </para>
<para>The timeline for the various release in the next month looks like this.
</para>
<programlisting>
Today Fix Enhancement Fix
Release 1 Release Release 2
|_______|______________|_________|
Time -->
</programlisting>
<para>We have two teams, one working on the bug fix branch and another team
working on the features for the next release on the main trunk. These
teams must make sure that they start out with the right version in
their sandbox.</para>
<orderedlist>
<listitem>
@ -960,15 +997,15 @@ they will update and commit their changes to the bug fix branch using the comman
line
<literallayout>
<command>
cvs update -R -r release_1_0_patches {project name}
cvs commit -R -r release_1_0_patches {project name}
cvs update -R -r release_1_0_patches {module name}
cvs commit -R -r release_1_0_patches {module name}
</command>
</literallayout>
</para>
<para>Now, the regular process of build test build is attempted and
a version is ready for delivery. The final version of the source code is
now committed into &CVSAB;. Now, two practices have to be followed.
<para>Now, the regular process of build-test-build is followed to make a
version ready for delivery. The final version of the source code is
committed into &CVSAB;. Now, two practices have to be followed.
</para>
<orderedlist>