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

Added some minor changes. Want to see how CVS handles timzeones

This commit is contained in:
vivekv 2001-12-01 16:17:04 +00:00
parent 070df24805
commit 756d94ea89
1 changed files with 45 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
LDP/ref/docbook/CVS-BestPractices/CVS-BestPractices.sgml
View File

@ -384,11 +384,10 @@ definite possibility of &CVSAB; getting confused. Thus system clocks must be
kept in sync by use of a central time server or similar mechanism. kept in sync by use of a central time server or similar mechanism.
</para> </para>
<note> <para>&CVSAB; is designed from ground up to handle multiple timezones. As
long as the host operating system has been setup and configured correctly,
<para>Can CVS handle clients situated in different timezone? This is an area &CVSAB; will be able to track changes correctly.
that is not very familiar to me. I would like to hear some thoughts on the </para>
same.</para>
</note> </note>
</sect2> </sect2>
@ -396,11 +395,11 @@ same.</para>
<sect2 id="section2-dontshare"> <sect2 id="section2-dontshare">
<title>Do not share the sandbox</title> <title>Do not share the sandbox</title>
<para>Sandboxes have to be unique for each developer or purpose. They should <para>Sandboxes have to be unique for each developer or purpose. They
not be used for multiple things at the same time. A sandbox can be a working should not be used for multiple things at the same time. A sandbox can be a
area for a developer or the build area for the final release. If such working area for a developer or the build area for the final release. If
sandboxes are shared, then the developers themselves will not be aware of the such sandboxes are shared, then the owner of the sandbox will not be aware
changes made to the files resulting in confusion. </para> of the changes made to the files resulting in confusion. </para>
<para>In &CVSAB;, the sandbox is created automatically when a working copy is <para>In &CVSAB;, the sandbox is created automatically when a working copy is
checked out for a &CVSAB; project using the <command>cvs checkout checked out for a &CVSAB; project using the <command>cvs checkout
@ -656,9 +655,9 @@ the application are migrated to other living versions of the application.
<sect2 id="section2-mergebugfix"> <sect2 id="section2-mergebugfix">
<title>Merge branch with the trunk after release</title> <title>Merge branch with the trunk after release</title>
<para>After each release from a branch, the changes made to the branch should <para>After each release from a branch, the changes made to the branch
be merged with the trunk. This ensures that all the bug fixes made to the should be merged with the trunk. This ensures that all the bug fixes made
patch release are properly incorporated into future releases of the to the patch release are properly incorporated into future releases of the
application. </para> application. </para>
<para>This merge could potentially be time consuming depending on the amount <para>This merge could potentially be time consuming depending on the amount
@ -669,18 +668,16 @@ application is in proper working order. This must be kept in mind while
preparing the project schedule. </para> preparing the project schedule. </para>
<para>In the case of changes occuring on branches for a long period of time, <para>In the case of changes occuring on branches for a long period of time,
these changes can be merged to the main branch on a regular basis even before these changes can be merged to the main branch on a regular basis even
the release is made. The frequency of merge is done based on certain logical before the release is made. The frequency of merge is done based on certain
points in the branch's evolution. To ensure that duplicate merging does not logical points in the branch's evolution. To ensure that duplicate merging
occur, the following practice can be adopted. does not occur, the following practice can be adopted. </para>
</para>
<para>In addition to the branch tag, a tag called {branch_name}_MERGED should be <para>In addition to the branch tag, a tag called {branch_name}_MERGED
created. This is initially at the same level as the last release tag for the should be created. This is initially at the same level as the last release
branch. This tag is then <quote>moved</quote> after each intermediate merge tag for the branch. This tag is then <quote>moved</quote> after each
by using the <command>-F</command> option. This eliminates duplicate merging intermediate merge by using the <command>-F</command> option. This
issues during intermediate merges. eliminates duplicate merging issues during intermediate merges. </para>
</para>
</sect2> </sect2>
</sect1> </sect1>
@ -698,20 +695,20 @@ binaries for daily work. </para>
<title>Build Early and Build Often (<acronym>BEBO</acronym>) </title> <title>Build Early and Build Often (<acronym>BEBO</acronym>) </title>
<para>A slight variation of this adage has been around in the &OPENSOURCE; <para>A slight variation of this adage has been around in the &OPENSOURCE;
community called "Release Early and Release Often" for quite some time albeit community called "Release Early and Release Often" for quite some time
for a different reason. BEBO helps a development team identify issues that albeit for a different reason. BEBO helps a development team identify
can arise from checking in the wrong files. BEBO will address issues that can arise from checking in the wrong files. BEBO will address
integration issues at the application level that might have slipped integration issues at the application level that might have slipped passed
passed individual developer builds. It will also improve the team morale when individual developer builds. It will also improve the team morale when they
they see a working version of the application.</para> see a working version of the application.</para>
<para>Builds must be done on a regular basis. There should be a dedicated <para>Builds must be done on a regular basis. There should be a dedicated
resource(s) assigned to do the same. The entire project team must be trained resource(s) assigned to do the same. The entire project team must be
to view the daily build as an important activity and not as a chore. Builds trained to view the daily build as an important activity and not as a chore.
must be completed without any failures on a regular basis. Build failures Builds must be completed without any failures on a regular basis. Build
must be a rare event and should be treated with utmost seriousness. The failures must be a rare event and should be treated with utmost seriousness.
project team should ensure that successful builds are top priority on their The project team should ensure that successful builds are top priority on
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>
</sect2> </sect2>
@ -743,11 +740,11 @@ announcements to ensure that the right version of source code is available
in the repository. </para> in the repository. </para>
<para>Automated build process as explained above will help in catching this <para>Automated build process as explained above will help in catching this
problem to a certain degree since they will automatically take the source code problem to a certain degree since they will automatically take the source
from the &CVSAB; repository and perform the software build. Any missed items code from the &CVSAB; repository and perform the software build. Any missed
will surface during the build process itself (makefiles etc.,) or during the items will surface during the build process itself (makefiles etc.,) or
regression testing of the product (older version of the file checked in). during the regression testing of the product (older version of the file
</para> checked in). </para>
<para>A penalty based system can be setup to handle wrong check-in. Having a <para>A penalty based system can be setup to handle wrong check-in. Having a
kitty for a post project party to which each person who makes a wrong check-in kitty for a post project party to which each person who makes a wrong check-in
@ -768,15 +765,14 @@ usage in the organization.
<title>Implement Change Management Process</title> <title>Implement Change Management Process</title>
<para>All organizations must implement a good Change management process <para>All organizations must implement a good Change management process
(<acronym>CMP</acronym>). A good CMP will define how changes are received and (<acronym>CMP</acronym>). A good CMP will define how changes are received
recorded, tracked, executed and delivered. &CVSAB; provides version control and recorded, tracked, executed and delivered. &CVSAB; provides version
for your project. Change management addresses the <quote>bigger control for your project. Change management addresses the <quote>bigger
picture</quote> of how enhancements and bugs are received, tracked and picture</quote> of how enhancements and bugs are received, tracked and
closed. &CVSAB; will play a smaller but a very important part in this closed. &CVSAB; will play a smaller but a very important part in this
entire picture. With a formal change management process in place in entire picture. With a formal change management process in place in the
the organization, tools such as &CVSAB; will be looked at as aiding organization, tools such as &CVSAB; will be looked at as aiding this process
this process instead of acting as a general development overhead. instead of acting as a general development overhead. </para>
</para>
<para>Change management is quite a vast topic that cannot be done justice <para>Change management is quite a vast topic that cannot be done justice
here. Please look up some websites on change management. </para> here. Please look up some websites on change management. </para>
@ -802,8 +798,7 @@ for the employee. </para>
<para>&CVSAB; usage metrics can be collected in terms of percentage of <para>&CVSAB; usage metrics can be collected in terms of percentage of
deployment in the organization, project size handled etc., This information deployment in the organization, project size handled etc., This information
will spur other line managers and program managers to look at &CVSAB; as a will spur other line managers and program managers to look at &CVSAB; as a
tool that will aid them in their daily operations. tool that will aid them in their daily operations. </para>
</para>
</sect2> </sect2>
</sect1> </sect1>