view release on metacpan or  search on metacpan

Docs/devmgr/devmgr.html  view on Meta::CPAN

The same tool <i>does not</i> have to be used for commits into the repository
as is used for check-outs from the repository. However, since the logic
is fundamentally the same for both operations, it has made sense from a
simplicity and maintenance point to have just the one tool.</li>

<li>
The current tool has all the host-specific data expressed in-line as an
extremely large data structure. In the past, roughly 90% of the errors
associated with adding a new external host as a supported system were related
to updates of this data structure. While the new method uses Oracle database
tables, not all the data needed by the wrapper is in the current tables
(necessitating expansion of the tables or design of new tables to accompany
them). Additionally, the overhead of accessing Oracle on every invocation
(particularly when one considers that large runs of successive invocations
will be for one given host) may well be worse than the overhead for parsing
the data structure each time.</li>

<li>
The use of these types of wrappers is no longer supported by the maintainers
of <tt>CVS</tt>. The 1.10 version currently in use was fetched from a third-party
site where users had re-enabled the functionality in the 1.10 source base.
Use of the wrappers cannot co-exist with the <tt>CVS</tt> client/server
model. Future releases of <tt>CVS</tt> won't have wrappers, and the third
party cannot be counted on to continue re-implementing this.</li>

<li>
The primary motivation for the wrappers is the legacy need for translating
the <tt>URI</tt>s of <tt>CGI</tt> applications. When the primary (and practiacally
only) machine was the host <tt>www.interactive.hp.com</tt>, all projects
shared a common CGI directory. To avoid name clashes, projects fanned out
from this point by project name. A <tt>URI</tt> of the form "<tt>/project/cgi-bin/app_name</tt>",
as it was known on the development machine, became "<tt>/cgi-bin/project/app_name</tt>"
on delivery. This required support at the <tt>CVS</tt> level, to re-write
these <tt>URI</tt>s dynamically. If this need can be eliminated, the wrappers
may be, as well.</li>
</ul>

<h2>
<a NAME="config"></a>6. The <tt>dev_release.cfg</tt> file</h2>
There are a variety of parameters that govern parts of the system's overall
functionality. These lend themselves to centralization in one file both
for the sake of sharing between applications and so that these values can
change independent of the actual program files. The applications look for
the configuration file by examining their own fully-qualified path within
the file system, dropping the last element of the path and then appending
"<tt>local</tt>". This is based on an assumption that the trailing element
of executables used in this system is "<tt>ahp-bin</tt>". Additionally,
to accommodate the suid-wrapper/symlink issue described earlier, the path
component "<tt>suid_scripts</tt>" is also checked for. If present, it is
simply discarded. In this directory, the file named <tt>dev_release.cfg</tt>
is expected to exist and contain the settings.
<p>The structure and format of the file is a simple sequence of lines of
the form:
<center><tt>NAME = VALUE</tt></center>
This should be obvious enough in style and intent. The amount of empty
space surrounding the equal sign is flexible. From the first non-whitespace
character to the right of the equal sign to the end of the current line
is all encompassed at the value of the parameter. This allows for parameters
with spaces within them. However, extra space <i>after</i> the last non-whitespace
character is removed. As an additional feature, lines may optionally start
with either of the special words, <tt>setenv</tt> or <tt>export</tt>. These
keywords are used by the C-shell and Korn shell, respectively, to set environment
variables. (The Bourne shell and "Bourne-Again" shell <tt>bash</tt> also
use <tt>export</tt> for environment variables.) To date, the flexibility
has not been needed, but it adds negligible overhead or complexity to the
tool, and leaves the option of future application open. Lastly, blank lines
are permitted for the sake of readability, and lines whose first character
is "<tt>#</tt>" are considered commentary and ignored.
<p>The values currently stored in the file, and their definitions, are:
<dl>
<dt>
<b>ACL_DIR</b></dt>

<dd>
Default: <tt>etc/acl</tt></dd>

<br>The directory in which the access-control lists (<tt>ACL</tt>) are
stored on a per-host basis. These files are described in more detail elsewhere,
but the short definition is that they govern which projects can release
to a specific target host, and which users are entitled to release a given
project. If the value is not an absolute path, it is considered relative
to the home directory of the <b><tt>USER</tt></b> defined below.
<dt>
<b>CVS</b></dt>

<dd>
Default: <tt>/opt/ims/bin/cvs</tt></dd>

<br>This is the fully-qualified path to the executable <tt>cvs</tt> program.
Specifying it here accomplishes two important goals: (1) the programs are
not reliant on the running user to have the correct directories in their
execution path, and (2) the danger of the tools being compromised by placement
of a dangerous program named <tt>cvs</tt> in an alternate element of the
execution path is eliminated. It also allows for the explicit selection
of a binary to use, a feature that was utilized when evaluating version
1.10 of <tt>CVS</tt>.
<dt>
<b>CVSROOT</b></dt>

<dd>
Default: <tt>/opt/ims/repository</tt></dd>

<br>The <tt>cvs</tt> command relies on either a command-line specification
of a repository root, or for the value to be defined in an environment
variable named <b><tt>CVSROOT</tt></b>. Defining it here not only guarantees
consistency, but also prevents errors or data loss due to an incorrectly-set
value on the user end.
<dt>
<b>DEVHOST</b></dt>

<dd>
Default: <tt>webdev.nafohq.hp.com</tt></dd>

<br>The fully-qualified-domain name of the development host the tools are
running on. This is not currently used to any real extent, but was planned
for use by the <i>wrapper</i> component.
<dt>
<b>EVENT_LOG</b></dt>

<dd>
Default: <tt>/opt/ims/htdocs/development-log.txt</tt></dd>