mirror of https://github.com/tLDP/LDP
Work in progress
This commit is contained in:
vivekv
parent
679ff77003
commit
109c61fd4f
|
|
@ -1,7 +1,7 @@
|
|||
<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
|
||||
|
||||
<!-- Document version -->
|
||||
<!ENTITY DOCVERSION "0.2">
|
||||
<!ENTITY DOCVERSION "0.3">
|
||||
|
||||
<!-- File Includes -->
|
||||
<!ENTITY GFDL-FILE SYSTEM "gfdl.sgml">
|
||||
|
|
@ -29,6 +29,14 @@
|
|||
</author>
|
||||
|
||||
<revhistory>
|
||||
|
||||
<revision>
|
||||
<revnumber>0.3</revnumber>
|
||||
<date>2001-12-01</date>
|
||||
<authorinitials>vv</authorinitials>
|
||||
<revremark>Grammatical errors</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>0.2</revnumber>
|
||||
<date>2001-11-27</date>
|
||||
|
|
@ -217,11 +225,11 @@ additions, comments and criticisms to the following email address :
|
|||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Do not work outside the sandbox
|
||||
<para>Stay in sync with the repository
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Stay in sync with the repository
|
||||
<para>Do not work outside the sandbox
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
|
@ -389,7 +397,6 @@ long as the host operating system has been setup and configured correctly,
|
|||
&CVSAB; will be able to track changes correctly.
|
||||
</para>
|
||||
|
||||
</note>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-dontshare">
|
||||
|
|
@ -414,44 +421,46 @@ the parts that are built by the developer. </para>
|
|||
<para>For example, in a Java project, the build team can keep the results of
|
||||
their last successful build in a standard location in the form of JAR files on
|
||||
the network file servers. Individual developers will use a standard classpath
|
||||
setup that has the network drives mounted on standard paths. Thus the
|
||||
setup that has the network drives mounted on standard paths. Thus, the
|
||||
developers will automatically get the latest version of the files as required
|
||||
by them.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-workinside">
|
||||
<title>Do not work outside the sandbox</title>
|
||||
|
||||
<para>The sandbox can be thought of as a controlled area within which &CVSAB;
|
||||
can track for changes made to the various source files. Files belonging to
|
||||
other developers will be automatically updated by &CVSAB;. Thus the developer
|
||||
who lives within the sandbox will stand to gain a lot of benefits of
|
||||
concurrent development. This benefit cannot be achieved for work done outside
|
||||
a sandbox. </para>
|
||||
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-syncup">
|
||||
<title>Stay in Sync with the repository</title>
|
||||
|
||||
<para>To gain the benefits of working within a sandbox as mentioned above,
|
||||
the developer must keep his or her sandbox in sync with the main
|
||||
repository. A regular <command>cvs update</command> with the appropriate
|
||||
tag or branch name will ensure that the sandboxes are kept up to date. </para> </sect2>
|
||||
the developer must keep his or her sandbox in sync with the main repository.
|
||||
A regular <command>cvs update</command> with the appropriate tag or branch
|
||||
name will ensure that the sandboxes are kept up to date. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-workinside">
|
||||
<title>Do not work outside the sandbox</title>
|
||||
|
||||
<para>The sandbox can be thought of as a controlled area within which
|
||||
&CVSAB; can track for changes made to the various source files. Files
|
||||
belonging to other developers will be automatically updated by &CVSAB;.
|
||||
Thus the developer who lives within the sandbox will stand to gain a lot of
|
||||
benefits of concurrent development. This benefit cannot be achieved for
|
||||
work done outside a sandbox. </para>
|
||||
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="section2-cleanupatcompletion">
|
||||
<title>Cleanup after completion</title>
|
||||
|
||||
<para>Make sure that the sandbox is cleaned up after completion of the change.
|
||||
This can be done in &CVSAB; by using the <command>cvs release</command>
|
||||
command. This ensures that no old version of the code exists in the
|
||||
development sandbox. As explained previously, pre-built binaries from the
|
||||
build team can be used to ensure that all the parts of the application are
|
||||
available to the developer without the need for a complete compilation in the
|
||||
sandbox.
|
||||
</para>
|
||||
<para>Make sure that the sandbox is cleaned up after completion of work on
|
||||
the files. Cleanup can be done in &CVSAB; by using the <command>cvs
|
||||
release</command> command. This ensures that no old version of the files
|
||||
exists in the development sandbox. As explained previously, pre-built
|
||||
binaries from the build team can be used to ensure that all the parts of the
|
||||
application are available to the developer without the need for a complete
|
||||
compilation in the sandbox. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
|
@ -459,24 +468,23 @@ sandbox.
|
|||
<title>Check-in Often</title>
|
||||
|
||||
<para>To help other developers keep their code in sync with your code, you
|
||||
must check-in your code often into the &CVSAB; repository. The best practice
|
||||
would be to check-in soon as a piece of code is completed, reviewed and
|
||||
tested, check-in the changes using a <command>cvs commit</command> to ensure
|
||||
that your changes are committed to the &CVSAB; repository.
|
||||
</para>
|
||||
must check-in your code often into the &CVSAB; repository. The best
|
||||
practice would be to check-in soon as a piece of code is completed, reviewed
|
||||
and tested, check-in the changes with <command>cvs commit</command> to
|
||||
ensure that your changes are committed to the &CVSAB; repository. </para>
|
||||
|
||||
<para> &CVSAB; promotes concurrent development. Concurrent development is
|
||||
possible only if all the other developers are aware of the ongoing changes on
|
||||
a regular basis. </para>
|
||||
possible only if all the other developers are aware of the ongoing changes
|
||||
on a regular basis. This awareness can be termed as <quote>situation
|
||||
awareness</quote> </para>
|
||||
|
||||
<note>
|
||||
<para>One of the <quote>bad</quote> practices that commonly occur is sharing
|
||||
of source code files between developers by email. This works against most of
|
||||
the best practices mentioned above. To share source code updates between two
|
||||
<warning> <para>One of the <quote>bad</quote> practices that commonly occur
|
||||
is the sharing of files between developers by email. This works against
|
||||
most of the best practices mentioned above. To share updates between two
|
||||
developers, &CVSAB; must be used as the communication medium. This will
|
||||
ensure that &CVSAB; is <quote>aware</quote> of the code change and can track
|
||||
ensure that &CVSAB; is <quote>aware</quote> of the changes and can track
|
||||
them. Thus, audit trail can be established if necessary. </para>
|
||||
</note>
|
||||
</warning>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
@ -498,13 +506,13 @@ best practices in this area. Suggestions are welcome.
|
|||
<sect2 id="section2-notification">
|
||||
<title>Server Notification</title>
|
||||
|
||||
<para>The &CVSAB; server can be configured to notify through e-mails in the
|
||||
event of a commit happening. This can be used to verify if code commits are
|
||||
occurring during the course of a release build. If such commits occur, based
|
||||
on the project policy, such commits can be ignored or the entire build
|
||||
automatically restarted.</para>
|
||||
</sect2>
|
||||
<para>The &CVSAB; server can be configured to notify through e-mails in case
|
||||
of a commit happening. This can be used to verify whether commits are
|
||||
occurring during the course of a daily/release build. If such commits
|
||||
occur, based on the project policy, the commits can be ignored or the entire
|
||||
build automatically restarted.</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="section1-branchmerge">
|
||||
|
|
@ -598,10 +606,11 @@ identifier is of the form. </para>
|
|||
|
||||
<para>After each software release, once the &CVSAB; repository is tagged, a
|
||||
branch has to be immediately created. This branch will serve as the bug fix
|
||||
branch for that release. This branch is created only if the release is not
|
||||
a bug fix or patch release. Patches that have to be made for this release
|
||||
at any point in time in the future will be developed on this branch. The
|
||||
main trunk will be used for ongoing product development. </para>
|
||||
baseline for that release. This branch is created only if the release is
|
||||
not a bug fix or patch release in the first place. Patches that have to be
|
||||
made for this release at any point in time in the future will be developed
|
||||
on this branch. The main trunk will be used for ongoing product
|
||||
development. </para>
|
||||
|
||||
<para>With this arrangement, the changes in the code for the ongoing
|
||||
development will be on the main trunk and the branch will provide a separate
|
||||
|
|
@ -632,7 +641,7 @@ accidentally. </para>
|
|||
</sect2>
|
||||
|
||||
<sect2 id="section2-patchesfrombranches">
|
||||
<title>Make patch release from branches only</title>
|
||||
<title>Make patch releases from branches only</title>
|
||||
|
||||
<para>Since all the bug fixes for a given release are done on its
|
||||
corresponding branch, the patch releases are made from the branch. This
|
||||
|
|
@ -667,7 +676,7 @@ After the merge, the trunk code base must be tested to verify that the
|
|||
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,
|
||||
<para>In the case of changes occurring on branches for a long period,
|
||||
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
|
||||
|
|
@ -687,10 +696,9 @@ eliminates duplicate merging issues during intermediate merges. </para>
|
|||
|
||||
<para>This section deals with the best practices for software builds. Build
|
||||
is the process of creating the application binaries for a software release.
|
||||
They are done in a periodic manner in development teams to provide baseline
|
||||
They are done in a periodic manner by the build teams to provide baseline
|
||||
binaries for daily work. </para>
|
||||
|
||||
|
||||
<sect2 id="section2-bebo">
|
||||
<title>Build Early and Build Often (<acronym>BEBO</acronym>) </title>
|
||||
|
||||
|
|
@ -735,7 +743,7 @@ less burdensome. </para>
|
|||
even with experienced development teams due to oversight. The problem of
|
||||
oversight cannot be easily addressed since the onus is on the individual
|
||||
developer to ensure that his or her file has been checked in. This practice
|
||||
should be drummed into the team in the form of trainings and pre-build
|
||||
should be drummed into the team in the form of training and pre-build
|
||||
announcements to ensure that the right version of source code is available
|
||||
in the repository. </para>
|
||||
|
||||
|
|
@ -775,7 +783,7 @@ 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>
|
||||
here. Please look up other sources of information on change management. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue