mirror of https://github.com/tLDP/LDP
new entries; new area of tree devoted to whitepapers, ref material, tutorials, etc...those that are not HOWTOs, FAQs or Guides.
This commit is contained in:
parent
daa546ffb3
commit
1702ef41ff
|
@ -0,0 +1,637 @@
|
|||
<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
|
||||
|
||||
<!-- Document version -->
|
||||
<!ENTITY DOCVERSION "0.1">
|
||||
|
||||
<!-- File Includes -->
|
||||
<!ENTITY GFDL-FILE SYSTEM "gfdl.sgml">
|
||||
|
||||
<!-- Text substitution macros -->
|
||||
<!ENTITY CVS "Concurrent Versions System">
|
||||
<!ENTITY OPENSOURCE "Open Source">
|
||||
<!ENTITY CVSAB "CVS">
|
||||
<!ENTITY SCMAB "SCM">
|
||||
<!ENTITY SCM "Software configuration management">
|
||||
<!ENTITY MYEMAIL "vivekv@users.sourceforge.net">
|
||||
|
||||
]>
|
||||
|
||||
<article>
|
||||
<title>CVS Best Practices</title>
|
||||
|
||||
<articleinfo>
|
||||
|
||||
<author>
|
||||
<firstname>Vivek</firstname>
|
||||
<surname>Venugopalan</surname>
|
||||
<affiliation>
|
||||
<address><email>vivekv@users.sourceforge.net</email></address></affiliation>
|
||||
</author>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>0.1</revnumber>
|
||||
<date>2001-11-20</date>
|
||||
<authorinitials>vv</authorinitials>
|
||||
<revremark>Created</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
</articleinfo>
|
||||
|
||||
<abstract>
|
||||
<indexterm>
|
||||
<primary>CVS Best Practices</primary>
|
||||
</indexterm>
|
||||
<para>This article explores some of the best practices that can be adopted
|
||||
while using CVS as the configuration management tool in your software
|
||||
projects.
|
||||
</para>
|
||||
</abstract>
|
||||
|
||||
<sect1 id="section1-intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
<blockquote>
|
||||
<attribution>unknown</attribution>
|
||||
<literallayout>A tool is only as good as you use it
|
||||
</literallayout>
|
||||
</blockquote>
|
||||
|
||||
<para>This article outlines some of the best practices that can be adopted
|
||||
when &CVS; is used as the configuration management tool in your software
|
||||
project. </para>
|
||||
|
||||
|
||||
<para>&CVS; (&CVSAB;) is an <ulink
|
||||
url="http://www.opensource.org">&OPENSOURCE;</ulink> configuration management
|
||||
tool that is now being looked at seriously by many commercial organizations as
|
||||
a viable alternative to other commercial &SCM; tools. </para>
|
||||
|
||||
<para>This spotlight on &CVSAB; has led to the inevitable question of best
|
||||
practices for deploying &CVSAB; as the backbone &SCMAB; tool for large
|
||||
software development projects. Having answered this question many times
|
||||
verbally as a bunch of <quote>gotchas</quote> on &CVSAB;, it was time to put
|
||||
down on paper some of the best practices that I have adopted while managing
|
||||
&CVSAB; based projects. </para>
|
||||
|
||||
<!-- Section2: copyright -->
|
||||
|
||||
<sect2 id="copyright">
|
||||
<title>Copyright Information</title>
|
||||
|
||||
<para> This document is Copyright © 2001 Vivek Venugopalan.
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the <link linkend="gfdl"><citetitle>GNU Free
|
||||
Documentation License</citetitle></link>, Version 1.1 or any later
|
||||
version published by the Free Software Foundation with no Invariant
|
||||
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the
|
||||
license can be found in <xref linkend="gfdl">.
|
||||
</para>
|
||||
|
||||
<para> This document may be reproduced and distributed in whole or in part,
|
||||
in any medium physical or electronic, as long as this copyright notice is
|
||||
retained on all copies. Commercial redistribution is allowed and encouraged;
|
||||
however, the author would like to be notified of any such distributions.
|
||||
</para>
|
||||
|
||||
<para> All translations, derivative works, or aggregate works incorporating
|
||||
this document must be covered under this copyright notice. That is, you may
|
||||
not produce a derivative work from this document and impose additional
|
||||
restrictions on its distribution. Exceptions to these rules may be granted
|
||||
under certain conditions; please contact the author at the
|
||||
address given below. </para>
|
||||
|
||||
<para> In short, we wish to promote dissemination of this information through
|
||||
as many channels as possible. However, we do wish to retain copyright on the
|
||||
document, and would like to be notified of any plans to redistribute
|
||||
the same. </para>
|
||||
|
||||
<para> If you have any questions, please contact
|
||||
<email>linux-howto@metalab.unc.edu</email> </para> </sect2>
|
||||
|
||||
<!-- Section2: disclaimer -->
|
||||
|
||||
<sect2 id="disclaimer"> <title>Disclaimer</title>
|
||||
|
||||
<para> No liability for the contents of this document can be accepted. Use
|
||||
the concepts, examples and other content at your own risk. As this is a new
|
||||
edition of this document, there may be errors and inaccuracies that may of
|
||||
course be damaging to your system. Proceed with caution, and although this is
|
||||
highly unlikely, the author(s) do not take any responsibility for that.
|
||||
</para>
|
||||
|
||||
<para> All copyrights are held by their respective owners, unless
|
||||
specifically noted otherwise. Use of a term in this document should not be
|
||||
regarded as affecting the validity of any trademark or service mark. </para>
|
||||
|
||||
<para> Naming of particular products or brands should not be seen as
|
||||
endorsements. </para>
|
||||
|
||||
<para> You are strongly recommended to take a backup of your system before
|
||||
major installation and backups at regular intervals. </para> </sect2>
|
||||
|
||||
<!-- Section2: newversions-->
|
||||
|
||||
<sect2 id="newversions">
|
||||
<title>New Versions</title>
|
||||
|
||||
<indexterm> <primary></primary> </indexterm>
|
||||
|
||||
<para> The version number of this document is &DOCVERSION;. </para>
|
||||
|
||||
<para> The latest version of this document can be obtained from <ulink
|
||||
url="http://www.linuxdoc.org">The linux documentation project</ulink> </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<!-- Section2: credits -->
|
||||
<!-- Nothing yet. Will do so after the first release and the feedback. -->
|
||||
<!-- Section2: feedback -->
|
||||
|
||||
<sect2 id="feedback">
|
||||
<title>Feedback</title>
|
||||
|
||||
<para> Feedback is most certainly welcome for this document. Without your
|
||||
submissions and input, this document wouldn't exist. Please send your
|
||||
additions, comments and criticisms to the following email address :
|
||||
<email>&MYEMAIL;</email>. </para> </sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="section1-focusareas">
|
||||
<title>Focus Areas</title>
|
||||
<para>The focus areas for best practice are
|
||||
</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>GUI Tools
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Use GUI tools for &CVSAB; client
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Developer Sandbox
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Do not share the sandbox
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Do not work outside the sandbox
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Stay in sync with the repository
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Check-in often
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Branching and Merging
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Assign ownership to trunk and branches
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Tag each release
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Create a branch after each release
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Make bug fixes to branches only
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Make patch releases from branches only
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Change propagation
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Merge branch with the trunk after each release
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Software Builds
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Build early and build often
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Automate build process completely
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>All necessary files must be checked in before a build
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Institutionalizing and Process
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Implement change management
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Make &CVSAB; usage part of developer's objectives
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Collect metrics on &CVSAB; usage
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<!-- Using GUI Tools -->
|
||||
|
||||
<sect1 id="section1-guitools">
|
||||
<title>Using GUI Tools</title>
|
||||
|
||||
<para> Developers typically use integrated development environments that have
|
||||
the CM tools integrated into them. These tools minimize the learning for the
|
||||
developers about the intricacies of &CVSAB; usage and instead allow them to be
|
||||
productive from day one. Developers who are accustomed to other CM tools will
|
||||
find the &CVSAB; command-line interface daunting. The adoption and usage of
|
||||
&CVSAB; can be improved by using GUI tools for &CVSAB; clients. GUI tools for
|
||||
&CVSAB; are available at <ulink url="www.cvsgui.org">www.cvsgui.org</ulink>.
|
||||
GUI interfaces are available for most of the popular platforms (Windows, Mac
|
||||
and Linux). In addition, on the Windows platform there is a SCC extension
|
||||
that allows integration of &CVSAB; as the configuration control tool with
|
||||
popular IDE.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="section1-devsandbox">
|
||||
<title>Developer Sandbox</title>
|
||||
|
||||
<para>The developer <quote>sandbox</quote> is where each developer keeps his
|
||||
or her working copy of the code base. This is where they build, test and
|
||||
debug the modules that they are working on. A sandbox can also be the area
|
||||
where the staging build or the production build is done. Changes made in
|
||||
the work area are checked into the &CVSAB; repository. In addition, changes
|
||||
made in the repository by others have to be updated in the sandbox on a
|
||||
regular basis. </para>
|
||||
|
||||
<para>The best practices related to developers sandbox are:
|
||||
</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
|
||||
workspaces are shared, then the developers themselves 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
|
||||
{project-name}</command> command. </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 can be automatically updated by &CVSAB;. Thus
|
||||
the developer who lives within the sandbox will stand to gain a lot of
|
||||
benefits of concurrent development that cannot be done if work is 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 workspace in sync with the main
|
||||
repository. A regular <command>cvs update</command> with the appropriate
|
||||
tag will ensure that the sandboxes are kept up to date. </para> </sect2>
|
||||
|
||||
<sect2 id="section2-checkin">
|
||||
<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. As soon as a
|
||||
piece of code is completed and tested, check-in the changes using a
|
||||
<command>cvs commit</command> to ensure that your changes are committed to
|
||||
the &CVSAB; repository. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="section1-branchmerge">
|
||||
<title>Branching and Merging</title>
|
||||
|
||||
<para> Branching in &CVSAB; splits a project's development into separate,
|
||||
parallel histories. Changes made on one branch do not affect the other
|
||||
branches. Branching can be used extensively to maintain multiple versions
|
||||
of a product for providing support and new features. </para>
|
||||
|
||||
<para> Merging converges the branches back to the main trunk. In a merge,
|
||||
CVS calculates the changes made on the branch between the point where it
|
||||
diverged from the trunk and the branch's tip (its most recent state), then
|
||||
applies those differences to the project at the tip of the trunk. </para>
|
||||
|
||||
<sect2 id="section2-branchowner">
|
||||
<title>Assign Ownership to Trunk and Branches</title>
|
||||
|
||||
<para>The main trunk of the source tree and the various branches should have a
|
||||
owner assigned who will be responsible for. </para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Establish a working policy for the branch or trunk.
|
||||
</para>
|
||||
|
||||
<para>The owner will establish policies for check-in and check-out. The
|
||||
policy will define when the code can be checked in (after coding or after
|
||||
review etc.,). Who is responsible to merge changes on the same file and
|
||||
resolve conflicts (the author or the person who recently changed the file).
|
||||
</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Identify and document policy deviations
|
||||
</para>
|
||||
|
||||
<para>Policies once established tend to have exceptions. The owner will be
|
||||
responsible for identifying the workaround and tracking/documenting the same
|
||||
for future use. </para>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Responsible for merge with the trunk
|
||||
</para>
|
||||
|
||||
<para>The branch owner will be responsible for ensuring that the changes in
|
||||
the branch can be successfully merged with the main trunk at a reasonable point
|
||||
in time. </para>
|
||||
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-tagrelease"> <title>Tag each release</title> <para>After
|
||||
each release, 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
|
||||
attached to the <quote>latest and greatest</quote> revisions in the
|
||||
repository). </para>
|
||||
|
||||
<para>The identifier for the tag should provide enough information to
|
||||
identify the release at any point in time in the future. One suggested tag
|
||||
identifier is of the form. </para>
|
||||
|
||||
<literallayout>
|
||||
<literal>release_</literal>{major version #}_{minor version #}
|
||||
</literallayout>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-branchatrelease">
|
||||
<title>Create a branch after each release</title>
|
||||
|
||||
<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>
|
||||
|
||||
<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
|
||||
partition for hot fixes and bug fix releases. </para>
|
||||
|
||||
<para>The identifier for the branch name can be of the form. </para>
|
||||
|
||||
<literallayout>
|
||||
<literal>release_</literal>{major version #}_{minor version #}<literal>_patches</literal>
|
||||
</literallayout>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-bugfixbranches">
|
||||
<title>Make bug fixes to branches only</title>
|
||||
|
||||
<para>This practice extends from the previous practice of creating a
|
||||
separate branch after a major release. The branch will serve as the code
|
||||
base for all bug fixes and patch release that have to be made. Thus, there
|
||||
is a separate repository <quote>sandbox</quote> where the hot fixes and
|
||||
patches can be developed apart from the mainstream development. </para>
|
||||
|
||||
<para>This practice also ensures that bug fixes done to previous releases do
|
||||
not mysteriously affect the mainstream version. In addition, new features
|
||||
added to the mainstream version do not creep into the patch release
|
||||
accidentally. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-patchesfrombranches">
|
||||
<title>Make patch release 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
|
||||
ensures that there is no confusion on the feature set that is released as
|
||||
part of the patch release. </para>
|
||||
|
||||
<para>After the patch release is made, the branch has to be tagged using the
|
||||
release tagging practice (see <xref linkend="section2-tagrelease">). </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="section1-chgpropagation">
|
||||
<title>Change Propagation</title>
|
||||
<para>Change propagation practices explores how changes made to one version of
|
||||
the application are migrated to other living versions of the application.
|
||||
</para>
|
||||
|
||||
<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
|
||||
application. </para>
|
||||
|
||||
<para>This merge could potentially be time consuming depending on the amount
|
||||
of changes made to the trunk and the branch being merged. In fact, it will
|
||||
probably result in a lot of conflicts in &CVSAB; resulting in manual merges.
|
||||
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>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="section1-softwarebuild">
|
||||
<title>Software Builds</title>
|
||||
|
||||
<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
|
||||
binaries for daily work. </para>
|
||||
|
||||
|
||||
<sect2 id="section2-bebo">
|
||||
<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>
|
||||
|
||||
<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
|
||||
breaking the build. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-automate">
|
||||
<title>Automate Build Process completely</title>
|
||||
|
||||
<para>Another key practice for software builds is to automate the build
|
||||
process completely. The automation process must also include automatic
|
||||
retrieval of the right source files from the &CVSAB; repository. This
|
||||
ensures that the build process is completely repeatable and consistent. In
|
||||
addition, the chances of a build with the wrong version of the application
|
||||
source files are reduced to a large degree. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-ensurecheckin">
|
||||
<title>All necessary files must be checked before build</title>
|
||||
|
||||
<para>This adage sounds trivial at first but this problem is very common
|
||||
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
|
||||
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>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="section1-instprocess">
|
||||
<title>Institutionalize &CVSAB; in the Organization</title>
|
||||
|
||||
<para>Here we will look at the best practices for institutionalizing &CVSAB;
|
||||
usage in the organization.
|
||||
</para>
|
||||
|
||||
<sect2 id="section2-chngmgmt">
|
||||
<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
|
||||
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>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-objectives">
|
||||
<title>Make &CVSAB; Usage part of Objectives</title>
|
||||
|
||||
<para>To institutionalize &CVSAB;, it can be made as part of the annual
|
||||
objectives for the developer to use it as part of his or her project. In addition,
|
||||
it can also be made as part of the objective for the project manager to deploy
|
||||
&CVSAB; in his or her project. </para>
|
||||
|
||||
<para>Compliance of this can then be reviewed as part of the appraisal cycle
|
||||
for the employee. </para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="section2-metrics">
|
||||
<title>Collect metrics on &CVSAB; usage</title>
|
||||
|
||||
<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>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="section1-conclusion">
|
||||
<title>Conclusion</title>
|
||||
|
||||
<para>These best practices are meant to help software teams get a head start
|
||||
on using &CVSAB; for their development. The ideas presented here have to be
|
||||
constantly reviewed and evolved. I would like this to be a growing and
|
||||
evolving document. Please send your comments and ideas to
|
||||
<email>&MYEMAIL;</email> </para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<!-- Include the GNU FDL -->
|
||||
&GFDL-FILE;
|
||||
|
||||
</article>
|
|
@ -0,0 +1,451 @@
|
|||
<appendix id="gfdl">
|
||||
<title>GNU Free Documentation License</title>
|
||||
<!-- - GNU Project - Free Software Foundation (FSF) -->
|
||||
<!-- LINK REV="made" HREF="mailto:webmasters@gnu.org" -->
|
||||
|
||||
|
||||
<!-- sect1>
|
||||
<title>GNU Free Documentation License</title -->
|
||||
|
||||
<para>Version 1.1, March 2000</para>
|
||||
|
||||
<blockquote>
|
||||
<para>Copyright (C) 2000 Free Software Foundation, Inc.
|
||||
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.</para>
|
||||
</blockquote>
|
||||
|
||||
<sect1 label="0">
|
||||
<title>Preamble</title>
|
||||
|
||||
<para>The purpose of this License is to make a manual, textbook,
|
||||
or other written document "free" in the sense of freedom: to
|
||||
assure everyone the effective freedom to copy and redistribute it,
|
||||
with or without modifying it, either commercially or
|
||||
noncommercially. Secondarily, this License preserves for the
|
||||
author and publisher a way to get credit for their work, while not
|
||||
being considered responsible for modifications made by
|
||||
others.</para>
|
||||
|
||||
<para>This License is a kind of "copyleft", which means that
|
||||
derivative works of the document must themselves be free in the
|
||||
same sense. It complements the GNU General Public License, which
|
||||
is a copyleft license designed for free software.</para>
|
||||
|
||||
<para>We have designed this License in order to use it for manuals
|
||||
for free software, because free software needs free documentation:
|
||||
a free program should come with manuals providing the same
|
||||
freedoms that the software does. But this License is not limited
|
||||
to software manuals; it can be used for any textual work,
|
||||
regardless of subject matter or whether it is published as a
|
||||
printed book. We recommend this License principally for works
|
||||
whose purpose is instruction or reference.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="1">
|
||||
<title>Applicability and Definitions</title>
|
||||
|
||||
<para>This License applies to any manual or other work that
|
||||
contains a notice placed by the copyright holder saying it can be
|
||||
distributed under the terms of this License. The "Document",
|
||||
below, refers to any such manual or work. Any member of the
|
||||
public is a licensee, and is addressed as "you".</para>
|
||||
|
||||
<para>A "Modified Version" of the Document means any work
|
||||
containing the Document or a portion of it, either copied
|
||||
verbatim, or with modifications and/or translated into another
|
||||
language.</para>
|
||||
|
||||
<para>A "Secondary Section" is a named appendix or a front-matter
|
||||
section of the Document that deals exclusively with the
|
||||
relationship of the publishers or authors of the Document to the
|
||||
Document's overall subject (or to related matters) and contains
|
||||
nothing that could fall directly within that overall subject.
|
||||
(For example, if the Document is in part a textbook of
|
||||
mathematics, a Secondary Section may not explain any mathematics.)
|
||||
The relationship could be a matter of historical connection with
|
||||
the subject or with related matters, or of legal, commercial,
|
||||
philosophical, ethical or political position regarding
|
||||
them.</para>
|
||||
|
||||
<para>The "Invariant Sections" are certain Secondary Sections
|
||||
whose titles are designated, as being those of Invariant Sections,
|
||||
in the notice that says that the Document is released under this
|
||||
License.</para>
|
||||
|
||||
<para>The "Cover Texts" are certain short passages of text that
|
||||
are listed, as Front-Cover Texts or Back-Cover Texts, in the
|
||||
notice that says that the Document is released under this
|
||||
License.</para>
|
||||
|
||||
<para>A "Transparent" copy of the Document means a
|
||||
machine-readable copy, represented in a format whose specification
|
||||
is available to the general public, whose contents can be viewed
|
||||
and edited directly and straightforwardly with generic text
|
||||
editors or (for images composed of pixels) generic paint programs
|
||||
or (for drawings) some widely available drawing editor, and that
|
||||
is suitable for input to text formatters or for automatic
|
||||
translation to a variety of formats suitable for input to text
|
||||
formatters. A copy made in an otherwise Transparent file format
|
||||
whose markup has been designed to thwart or discourage subsequent
|
||||
modification by readers is not Transparent. A copy that is not
|
||||
"Transparent" is called "Opaque".</para>
|
||||
|
||||
<para>Examples of suitable formats for Transparent copies include
|
||||
plain ASCII without markup, Texinfo input format, LaTeX input
|
||||
format, SGML or XML using a publicly available DTD, and
|
||||
standard-conforming simple HTML designed for human modification.
|
||||
Opaque formats include PostScript, PDF, proprietary formats that
|
||||
can be read and edited only by proprietary word processors, SGML
|
||||
or XML for which the DTD and/or processing tools are not generally
|
||||
available, and the machine-generated HTML produced by some word
|
||||
processors for output purposes only.</para>
|
||||
|
||||
<para>The "Title Page" means, for a printed book, the title page
|
||||
itself, plus such following pages as are needed to hold, legibly,
|
||||
the material this License requires to appear in the title page.
|
||||
For works in formats which do not have any title page as such,
|
||||
"Title Page" means the text near the most prominent appearance of
|
||||
the work's title, preceding the beginning of the body of the
|
||||
text.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="2">
|
||||
<title>Verbatim Copying</title>
|
||||
|
||||
<para>You may copy and distribute the Document in any medium,
|
||||
either commercially or noncommercially, provided that this
|
||||
License, the copyright notices, and the license notice saying this
|
||||
License applies to the Document are reproduced in all copies, and
|
||||
that you add no other conditions whatsoever to those of this
|
||||
License. You may not use technical measures to obstruct or
|
||||
control the reading or further copying of the copies you make or
|
||||
distribute. However, you may accept compensation in exchange for
|
||||
copies. If you distribute a large enough number of copies you
|
||||
must also follow the conditions in section 3.</para>
|
||||
|
||||
<para>You may also lend copies, under the same conditions stated
|
||||
above, and you may publicly display copies.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="3">
|
||||
<title>Copying in Quantity</title>
|
||||
|
||||
<para>If you publish printed copies of the Document numbering more
|
||||
than 100, and the Document's license notice requires Cover Texts,
|
||||
you must enclose the copies in covers that carry, clearly and
|
||||
legibly, all these Cover Texts: Front-Cover Texts on the front
|
||||
cover, and Back-Cover Texts on the back cover. Both covers must
|
||||
also clearly and legibly identify you as the publisher of these
|
||||
copies. The front cover must present the full title with all
|
||||
words of the title equally prominent and visible. You may add
|
||||
other material on the covers in addition. Copying with changes
|
||||
limited to the covers, as long as they preserve the title of the
|
||||
Document and satisfy these conditions, can be treated as verbatim
|
||||
copying in other respects.</para>
|
||||
|
||||
<para>If the required texts for either cover are too voluminous to
|
||||
fit legibly, you should put the first ones listed (as many as fit
|
||||
reasonably) on the actual cover, and continue the rest onto
|
||||
adjacent pages.</para>
|
||||
|
||||
<para>If you publish or distribute Opaque copies of the Document
|
||||
numbering more than 100, you must either include a
|
||||
machine-readable Transparent copy along with each Opaque copy, or
|
||||
state in or with each Opaque copy a publicly-accessible
|
||||
computer-network location containing a complete Transparent copy
|
||||
of the Document, free of added material, which the general
|
||||
network-using public has access to download anonymously at no
|
||||
charge using public-standard network protocols. If you use the
|
||||
latter option, you must take reasonably prudent steps, when you
|
||||
begin distribution of Opaque copies in quantity, to ensure that
|
||||
this Transparent copy will remain thus accessible at the stated
|
||||
location until at least one year after the last time you
|
||||
distribute an Opaque copy (directly or through your agents or
|
||||
retailers) of that edition to the public.</para>
|
||||
|
||||
<para>It is requested, but not required, that you contact the
|
||||
authors of the Document well before redistributing any large
|
||||
number of copies, to give them a chance to provide you with an
|
||||
updated version of the Document.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="4">
|
||||
<title>Modifications</title>
|
||||
|
||||
<para>You may copy and distribute a Modified Version of the
|
||||
Document under the conditions of sections 2 and 3 above, provided
|
||||
that you release the Modified Version under precisely this
|
||||
License, with the Modified Version filling the role of the
|
||||
Document, thus licensing distribution and modification of the
|
||||
Modified Version to whoever possesses a copy of it. In addition,
|
||||
you must do these things in the Modified Version:</para>
|
||||
|
||||
<orderedlist numeration="upperalpha">
|
||||
<listitem><para>Use in the Title Page
|
||||
(and on the covers, if any) a title distinct from that of the
|
||||
Document, and from those of previous versions (which should, if
|
||||
there were any, be listed in the History section of the
|
||||
Document). You may use the same title as a previous version if
|
||||
the original publisher of that version gives permission.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>List on the Title Page,
|
||||
as authors, one or more persons or entities responsible for
|
||||
authorship of the modifications in the Modified Version,
|
||||
together with at least five of the principal authors of the
|
||||
Document (all of its principal authors, if it has less than
|
||||
five).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>State on the Title page
|
||||
the name of the publisher of the Modified Version, as the
|
||||
publisher.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Preserve all the
|
||||
copyright notices of the Document.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Add an appropriate
|
||||
copyright notice for your modifications adjacent to the other
|
||||
copyright notices.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Include, immediately
|
||||
after the copyright notices, a license notice giving the public
|
||||
permission to use the Modified Version under the terms of this
|
||||
License, in the form shown in the Addendum below.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Preserve in that license
|
||||
notice the full lists of Invariant Sections and required Cover
|
||||
Texts given in the Document's license notice.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Include an unaltered
|
||||
copy of this License.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Preserve the section
|
||||
entitled "History", and its title, and add to it an item stating
|
||||
at least the title, year, new authors, and publisher of the
|
||||
Modified Version as given on the Title Page. If there is no
|
||||
section entitled "History" in the Document, create one stating
|
||||
the title, year, authors, and publisher of the Document as given
|
||||
on its Title Page, then add an item describing the Modified
|
||||
Version as stated in the previous sentence.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Preserve the network
|
||||
location, if any, given in the Document for public access to a
|
||||
Transparent copy of the Document, and likewise the network
|
||||
locations given in the Document for previous versions it was
|
||||
based on. These may be placed in the "History" section. You
|
||||
may omit a network location for a work that was published at
|
||||
least four years before the Document itself, or if the original
|
||||
publisher of the version it refers to gives permission.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>In any section entitled
|
||||
"Acknowledgements" or "Dedications", preserve the section's
|
||||
title, and preserve in the section all the substance and tone of
|
||||
each of the contributor acknowledgements and/or dedications
|
||||
given therein.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Preserve all the
|
||||
Invariant Sections of the Document, unaltered in their text and
|
||||
in their titles. Section numbers or the equivalent are not
|
||||
considered part of the section titles.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Delete any section
|
||||
entitled "Endorsements". Such a section may not be included in
|
||||
the Modified Version.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Do not retitle any
|
||||
existing section as "Endorsements" or to conflict in title with
|
||||
any Invariant Section.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If the Modified Version includes new front-matter sections
|
||||
or appendices that qualify as Secondary Sections and contain no
|
||||
material copied from the Document, you may at your option
|
||||
designate some or all of these sections as invariant. To do this,
|
||||
add their titles to the list of Invariant Sections in the Modified
|
||||
Version's license notice. These titles must be distinct from any
|
||||
other section titles.</para>
|
||||
|
||||
<para>You may add a section entitled "Endorsements", provided it
|
||||
contains nothing but endorsements of your Modified Version by
|
||||
various parties--for example, statements of peer review or that
|
||||
the text has been approved by an organization as the authoritative
|
||||
definition of a standard.</para>
|
||||
|
||||
<para>You may add a passage of up to five words as a Front-Cover
|
||||
Text, and a passage of up to 25 words as a Back-Cover Text, to the
|
||||
end of the list of Cover Texts in the Modified Version. Only one
|
||||
passage of Front-Cover Text and one of Back-Cover Text may be
|
||||
added by (or through arrangements made by) any one entity. If the
|
||||
Document already includes a cover text for the same cover,
|
||||
previously added by you or by arrangement made by the same entity
|
||||
you are acting on behalf of, you may not add another; but you may
|
||||
replace the old one, on explicit permission from the previous
|
||||
publisher that added the old one.</para>
|
||||
|
||||
<para>The author(s) and publisher(s) of the Document do not by
|
||||
this License give permission to use their names for publicity for
|
||||
or to assert or imply endorsement of any Modified Version.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="5">
|
||||
<title>Combining Documents</title>
|
||||
|
||||
<para>You may combine the Document with other documents released
|
||||
under this License, under the terms defined in section 4 above for
|
||||
modified versions, provided that you include in the combination
|
||||
all of the Invariant Sections of all of the original documents,
|
||||
unmodified, and list them all as Invariant Sections of your
|
||||
combined work in its license notice.</para>
|
||||
|
||||
<para>The combined work need only contain one copy of this
|
||||
License, and multiple identical Invariant Sections may be replaced
|
||||
with a single copy. If there are multiple Invariant Sections with
|
||||
the same name but different contents, make the title of each such
|
||||
section unique by adding at the end of it, in parentheses, the
|
||||
name of the original author or publisher of that section if known,
|
||||
or else a unique number. Make the same adjustment to the section
|
||||
titles in the list of Invariant Sections in the license notice of
|
||||
the combined work.</para>
|
||||
|
||||
<para>In the combination, you must combine any sections entitled
|
||||
"History" in the various original documents, forming one section
|
||||
entitled "History"; likewise combine any sections entitled
|
||||
"Acknowledgements", and any sections entitled "Dedications". You
|
||||
must delete all sections entitled "Endorsements."</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="6">
|
||||
<title>Collections of Documents</title>
|
||||
|
||||
<para>You may make a collection consisting of the Document and
|
||||
other documents released under this License, and replace the
|
||||
individual copies of this License in the various documents with a
|
||||
single copy that is included in the collection, provided that you
|
||||
follow the rules of this License for verbatim copying of each of
|
||||
the documents in all other respects.</para>
|
||||
|
||||
<para>You may extract a single document from such a collection,
|
||||
and distribute it individually under this License, provided you
|
||||
insert a copy of this License into the extracted document, and
|
||||
follow this License in all other respects regarding verbatim
|
||||
copying of that document.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="7">
|
||||
<title>Aggregation with Independent Works</title>
|
||||
|
||||
<para>A compilation of the Document or its derivatives with other
|
||||
separate and independent documents or works, in or on a volume of
|
||||
a storage or distribution medium, does not as a whole count as a
|
||||
Modified Version of the Document, provided no compilation
|
||||
copyright is claimed for the compilation. Such a compilation is
|
||||
called an "aggregate", and this License does not apply to the
|
||||
other self-contained works thus compiled with the Document, on
|
||||
account of their being thus compiled, if they are not themselves
|
||||
derivative works of the Document.</para>
|
||||
|
||||
<para>If the Cover Text requirement of section 3 is applicable to
|
||||
these copies of the Document, then if the Document is less than
|
||||
one quarter of the entire aggregate, the Document's Cover Texts
|
||||
may be placed on covers that surround only the Document within the
|
||||
aggregate. Otherwise they must appear on covers around the whole
|
||||
aggregate.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="8">
|
||||
<title>Translation</title>
|
||||
|
||||
<para>Translation is considered a kind of modification, so you may
|
||||
distribute translations of the Document under the terms of section
|
||||
4. Replacing Invariant Sections with translations requires
|
||||
special permission from their copyright holders, but you may
|
||||
include translations of some or all Invariant Sections in addition
|
||||
to the original versions of these Invariant Sections. You may
|
||||
include a translation of this License provided that you also
|
||||
include the original English version of this License. In case of
|
||||
a disagreement between the translation and the original English
|
||||
version of this License, the original English version will
|
||||
prevail.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="9">
|
||||
<title>Termination</title>
|
||||
|
||||
<para>You may not copy, modify, sublicense, or distribute the
|
||||
Document except as expressly provided for under this License. Any
|
||||
other attempt to copy, modify, sublicense or distribute the
|
||||
Document is void, and will automatically terminate your rights
|
||||
under this License. However, parties who have received copies, or
|
||||
rights, from you under this License will not have their licenses
|
||||
terminated so long as such parties remain in full
|
||||
compliance.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="10">
|
||||
<title>Future Revisions of this License</title>
|
||||
|
||||
<para>The Free Software Foundation may publish new, revised
|
||||
versions of the GNU Free Documentation License from time to time.
|
||||
Such new versions will be similar in spirit to the present
|
||||
version, but may differ in detail to address new problems or
|
||||
concerns. See <ulink
|
||||
url="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</ulink>.</para>
|
||||
|
||||
<para>Each version of the License is given a distinguishing
|
||||
version number. If the Document specifies that a particular
|
||||
numbered version of this License "or any later version" applies to
|
||||
it, you have the option of following the terms and conditions
|
||||
either of that specified version or of any later version that has
|
||||
been published (not as a draft) by the Free Software Foundation.
|
||||
If the Document does not specify a version number of this License,
|
||||
you may choose any version ever published (not as a draft) by the
|
||||
Free Software Foundation.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 label="">
|
||||
<title>How to use this License for your documents</title>
|
||||
|
||||
<para>To use this License in a document you have written, include
|
||||
a copy of the License in the document and put the following
|
||||
copyright and license notices just after the title page:</para>
|
||||
|
||||
<blockquote><para>
|
||||
Copyright (c) YEAR YOUR NAME.
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.1
|
||||
or any later version published by the Free Software Foundation;
|
||||
with the Invariant Sections being LIST THEIR TITLES, with the
|
||||
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
|
||||
A copy of the license is included in the section entitled "GNU
|
||||
Free Documentation License".
|
||||
</para></blockquote>
|
||||
|
||||
<para>If you have no Invariant Sections, write "with no Invariant
|
||||
Sections" instead of saying which ones are invariant. If you have
|
||||
no Front-Cover Texts, write "no Front-Cover Texts" instead of
|
||||
"Front-Cover Texts being LIST"; likewise for Back-Cover
|
||||
Texts.</para>
|
||||
|
||||
<para>If your document contains nontrivial examples of program
|
||||
code, we recommend releasing these examples in parallel under your
|
||||
choice of free software license, such as the GNU General Public
|
||||
License, to permit their use in free software.</para>
|
||||
</sect1>
|
||||
|
||||
</appendix>
|
||||
|
Loading…
Reference in New Issue