head	1.2;
access;
symbols;
locks; strict;
comment	@# @;


1.2
date	2001.08.08.20.03.13;	author edk;	state Exp;
branches;
next	1.1;

1.1
date	2001.08.08.18.31.21;	author edk;	state Exp;
branches;
next	;


desc
@@


1.2
log
@fix product reference
@
text
@<html><head><title>Data</title></head>
<body>
<h2>Overview</h2>

This document contains a technical outline of the data which is stored in
different parts of the sandbox and in other locations.

<h3>cvs</h3>
All of the cvs data is contained within $SANDBOX/data/helm/cvs.  In a
production environment, typically /cvs is a symlink for
$SANDBOX/data/helm/cvs/repository.

<p>
In addition to data, $SANDBOX/data/helm/cvs/repository/CVSROOT/ contains
application configuration (files which we use to control who cvs operates,
which tend to change from version to version of tigris.

<h3>qmail</h3>
qmail contains mail which is in transit in /var/qmail/spool

<h3>anzu</h3>

anzu contains all of its data in $SANDBOX/data/anzu.  This data includes the
ezmlm data, which is contained in nested subdirectories of the anzu data
directory.  anzu stores some meta information about mailing lists and mailing
list types in various files.

<p>In addition to data, some application configuration is stored in the anzu
data directory.

<h3>issuezilla</h3>
issuezilla stores information in the database (in one or more dedicated
databases named issues or issues_*), and in $SANDBOX/issuezilla/{shadow,data}
-- these are apparently only used to cache information, and could lost during
upgrades.

<h3>eyebrowse</h3>
eyebrowse stores information in the database (in the same database as helm)
and in $SANDBOX/data/eyebrowse/ in mbox files and in lucene index files. 

<h3>htdoc root</h3>
This directory contains the files published through remote branding.
Historically, it also contained MHonArc archives (which are no longer in use
save as a legacy issue) and a symlink to the scp upload account (for
netbeans).

<p>In the future, this directory shouldn't have any data which isn't directly
reproducible from the cvs repository; it is maintained separately for
efficiency.  Note that helm and the instance module will generally put
information into either the htdocroot or the cvs repository during install.sh
and dev-install.sh.

<h3>nidaba/fileserv</h3>
$SANDBOX/data/helm/fileserv/ contains uploaded files used project downloads
and project documents.  This directory has been changed in the head (*).
Some of the information required to deal with these files is also maintained
in the database.

<h3>helm</h3>

$SANDBOX/data/helm/ has five subdirectories 
<ul>
<li>apache (obsolete)
<li>cvs (described above)
<li>fileserve (described above)
<li>htdoc (described above)
<li>qmail (used for .qmail files for the tigrisq user -- this should move into
a different directory, because it's application configuration, not data).  
</ul>

In addition, helm stores data in the the rdbms, in a database called tigris or
tigris_${UID}.

<h3>mysql database</h3>

mysql is used to store information for lots of different components.  All of
the files are stored in /var/lib/mysql.

<h3>bootstrap database creation</h3>
In 1.0.x, the following statements apply to helm and to the instance, with
some special handling of issuezilla and eyebrowse.  In the HEAD, it's
generally possible for other components.

<p>
The database creation and population with initial data is done through
$SANDBOX/site/sql/$component directories.  Each such directory can have a
LoadOrder.lst, as well as files which match helm's.  The sequence is generally
to create the schema, and then to populate it as appropriate, generally by
running a list of populate_* scripts in the correct sequence.

</body></html>
@


1.1
log
@provide an outline of the different data stores in use in a tigris install
@
text
@d16 1
a16 1
which tend to change from version to version of sourcecase.
@

