mirror of https://github.com/tLDP/LDP
Added some minor changes. Want to see how CVS handles timzeones
This commit is contained in:
vivekv
parent
070df24805
commit
756d94ea89
|
|
@ -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.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
|
||||
<para>Can CVS handle clients situated in different timezone? This is an area
|
||||
that is not very familiar to me. I would like to hear some thoughts on the
|
||||
same.</para>
|
||||
<para>&CVSAB; is designed from ground up to handle multiple timezones. As
|
||||
long as the host operating system has been setup and configured correctly,
|
||||
&CVSAB; will be able to track changes correctly.
|
||||
</para>
|
||||
|
||||
</note>
|
||||
</sect2>
|
||||
|
|
@ -396,11 +395,11 @@ same.</para>
|
|||
<sect2 id="section2-dontshare">
|
||||
<title>Do not share the sandbox</title>
|
||||
|
||||
<para>Sandboxes have to be unique for each developer or purpose. They should
|
||||
not be used for multiple things at the same time. A sandbox can be a working
|
||||
area for a developer or the build area for the final release. If such
|
||||
sandboxes are shared, then the developers themselves will not be aware of the
|
||||
changes made to the files resulting in confusion. </para>
|
||||
<para>Sandboxes have to be unique for each developer or purpose. They
|
||||
should not be used for multiple things at the same time. A sandbox can be a
|
||||
working area for a developer or the build area for the final release. If
|
||||
such sandboxes are shared, then the owner of the sandbox will not be aware
|
||||
of the changes made to the files resulting in confusion. </para>
|
||||
|
||||
<para>In &CVSAB;, the sandbox is created automatically when a working copy is
|
||||
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">
|
||||
<title>Merge branch with the trunk after release</title>
|
||||
|
||||
<para>After each release from a branch, the changes made to the branch should
|
||||
be merged with the trunk. This ensures that all the bug fixes made to the
|
||||
patch release are properly incorporated into future releases of the
|
||||
<para>After each release from a branch, the changes made to the branch
|
||||
should be merged with the trunk. This ensures that all the bug fixes made
|
||||
to the patch release are properly incorporated into future releases of the
|
||||
application. </para>
|
||||
|
||||
<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>
|
||||
|
||||
<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
|
||||
the release is made. The frequency of merge is done based on certain logical
|
||||
points in the branch's evolution. To ensure that duplicate merging does not
|
||||
occur, the following practice can be adopted.
|
||||
</para>
|
||||
these changes can be merged to the main branch on a regular basis even
|
||||
before the release is made. The frequency of merge is done based on certain
|
||||
logical points in the branch's evolution. To ensure that duplicate merging
|
||||
does not occur, the following practice can be adopted. </para>
|
||||
|
||||
<para>In addition to the branch tag, a tag called {branch_name}_MERGED should be
|
||||
created. This is initially at the same level as the last release tag for the
|
||||
branch. This tag is then <quote>moved</quote> after each intermediate merge
|
||||
by using the <command>-F</command> option. This eliminates duplicate merging
|
||||
issues during intermediate merges.
|
||||
</para>
|
||||
<para>In addition to the branch tag, a tag called {branch_name}_MERGED
|
||||
should be created. This is initially at the same level as the last release
|
||||
tag for the branch. This tag is then <quote>moved</quote> after each
|
||||
intermediate merge by using the <command>-F</command> option. This
|
||||
eliminates duplicate merging issues during intermediate merges. </para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
@ -698,20 +695,20 @@ binaries for daily work. </para>
|
|||
<title>Build Early and Build Often (<acronym>BEBO</acronym>) </title>
|
||||
|
||||
<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
|
||||
for a different reason. BEBO helps a development team identify issues that
|
||||
can arise from checking in the wrong files. BEBO will address
|
||||
integration issues at the application level that might have slipped
|
||||
passed individual developer builds. It will also improve the team morale when
|
||||
they see a working version of the application.</para>
|
||||
community called "Release Early and Release Often" for quite some time
|
||||
albeit for a different reason. BEBO helps a development team identify
|
||||
issues that can arise from checking in the wrong files. BEBO will address
|
||||
integration issues at the application level that might have slipped passed
|
||||
individual developer builds. It will also improve the team morale when they
|
||||
see a working version of the application.</para>
|
||||
|
||||
<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
|
||||
to view the daily build as an important activity and not as a chore. Builds
|
||||
must be completed without any failures on a regular basis. Build failures
|
||||
must be a rare event and should be treated with utmost seriousness. 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
|
||||
resource(s) assigned to do the same. The entire project team must be
|
||||
trained to view the daily build as an important activity and not as a chore.
|
||||
Builds must be completed without any failures on a regular basis. Build
|
||||
failures must be a rare event and should be treated with utmost seriousness.
|
||||
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
|
||||
breaking the build. </para>
|
||||
|
||||
</sect2>
|
||||
|
|
@ -743,11 +740,11 @@ announcements to ensure that the right version of source code is available
|
|||
in the repository. </para>
|
||||
|
||||
<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
|
||||
from the &CVSAB; repository and perform the software build. Any missed items
|
||||
will surface during the build process itself (makefiles etc.,) or during the
|
||||
regression testing of the product (older version of the file checked in).
|
||||
</para>
|
||||
problem to a certain degree since they will automatically take the source
|
||||
code from the &CVSAB; repository and perform the software build. Any missed
|
||||
items will surface during the build process itself (makefiles etc.,) or
|
||||
during the regression testing of the product (older version of the file
|
||||
checked in). </para>
|
||||
|
||||
<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
|
||||
|
|
@ -768,15 +765,14 @@ usage in the organization.
|
|||
<title>Implement Change Management Process</title>
|
||||
|
||||
<para>All organizations must implement a good Change management process
|
||||
(<acronym>CMP</acronym>). A good CMP will define how changes are received and
|
||||
recorded, tracked, executed and delivered. &CVSAB; provides version control
|
||||
for your project. Change management addresses the <quote>bigger
|
||||
(<acronym>CMP</acronym>). A good CMP will define how changes are received
|
||||
and recorded, tracked, executed and delivered. &CVSAB; provides version
|
||||
control for your project. Change management addresses the <quote>bigger
|
||||
picture</quote> of how enhancements and bugs are received, tracked and
|
||||
closed. &CVSAB; will play a smaller but a very important part in this
|
||||
entire picture. With a formal change management process in place in
|
||||
the organization, tools such as &CVSAB; will be looked at as aiding
|
||||
this process instead of acting as a general development overhead.
|
||||
</para>
|
||||
entire picture. With a formal change management process in place in the
|
||||
organization, tools such as &CVSAB; will be looked at as aiding this process
|
||||
instead of acting as a general development overhead. </para>
|
||||
|
||||
<para>Change management is quite a vast topic that cannot be done justice
|
||||
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
|
||||
deployment in the organization, project size handled etc., This information
|
||||
will spur other line managers and program managers to look at &CVSAB; as a
|
||||
tool that will aid them in their daily operations.
|
||||
</para>
|
||||
tool that will aid them in their daily operations. </para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
|
|||
Loading…
Reference in New Issue