head	1.8;
access;
symbols
	TIGRIS_1_1_0RC2:1.7.12.1
	TIGRIS_1_1_0RC1:1.7.12.1
	TIGRIS_1_1:1.7.0.12
	TIGRIS_1_0_8:1.7
	TIGRIS_1_0_8RC3:1.7
	TIGRIS_1_0_8RC2:1.7
	TIGRIS_1_0_8RC1:1.7
	TIGRIS_1_0_7:1.7
	TIGRIS_1_0_7RC3:1.7
	TIGRIS_1_0_7RC2:1.7
	TIGRIS_1_0_7RC1:1.7
	TIGRIS_1_0_6:1.7
	TIGRIS_1_0_6RC5:1.7
	TIGRIS_1_0_6RC4:1.7
	TIGRIS_1_0_6RC3:1.7
	TIGRIS_1_0_6RC2:1.7
	TIGRIS_1_0_6RC1:1.7
	TIGRIS_1_0_5:1.7
	TIGRIS_1_0_5RC6:1.7
	TIGRIS_1_0_5RC5:1.7
	TIGRIS_1_0_5RC4:1.7
	TIGRIS_1_0_5RC3:1.7
	TIGRIS_1_0_5RC2:1.7
	TIGRIS_1_0_5RC1:1.7
	TIGRIS_1_0_4:1.7
	TIGRIS_1_0_3:1.7
	TIGRIS_1_0_2:1.7
	TIGRIS_1_0_1:1.7
	TIGRIS_1_0:1.7.0.14
	TIGRIS_1_0_0:1.7
	TIGRIS_1_0_0_RC1:1.7.0.10
	HELM_PEER_PORT_BRANCH:1.7.0.8
	TIGRIS_0_9_2_4:1.7
	TIGRIS_0_9_2_3:1.7
	TIGRIS_0_9_2:1.7.0.6
	TIGRIS_0_9_0:1.7.0.4
	ISSUEZILLA_OPENOFFICE:1.4.0.4
	IZ_TEMP_TAG:1.4
	TIGRIS_0_8_4:1.7.0.2
	ISSUEZILLA_11292000:1.7
	ISSUEZILLA_BASELINE:1.4.0.2
	ISSUEZILLA_BASELINE_BASE:1.4
	ISSUEZILLA_11062000:1.7
	TIGRIS_710_FF:1.6
	TIGRIS_706:1.6
	ISSUEZILLA_10252000:1.5
	TIGRIS_SEP_13_2000:1.5.0.2
	TIGRIS_705:1.5
	TIGRIS_704:1.5
	TIGRIS_703:1.5
	TIGRIS_702:1.4
	TIGRIS_701:1.4;
locks; strict;
comment	@# @;


1.8
date	2001.04.30.20.56.14;	author kmaples;	state dead;
branches;
next	1.7;

1.7
date	2000.11.06.19.15.07;	author kmaples;	state Exp;
branches
	1.7.2.1
	1.7.12.1;
next	1.6;

1.6
date	2000.10.26.05.19.31;	author edk;	state Exp;
branches;
next	1.5;

1.5
date	2000.10.18.21.43.46;	author kmaples;	state Exp;
branches;
next	1.4;

1.4
date	2000.09.29.06.49.57;	author npm;	state Exp;
branches;
next	1.3;

1.3
date	2000.09.28.04.49.40;	author npm;	state Exp;
branches;
next	1.2;

1.2
date	2000.09.28.04.47.01;	author npm;	state Exp;
branches;
next	1.1;

1.1
date	2000.09.28.04.28.27;	author npm;	state Exp;
branches;
next	;

1.7.2.1
date	2001.05.23.17.36.27;	author kmaples;	state Exp;
branches;
next	;

1.7.12.1
date	2001.08.03.00.34.38;	author jasonb;	state Exp;
branches;
next	;


desc
@@


1.8
log
@Issuezilla is now a separate module
@
text
@Notes on Bugzilla/IssueZilla:

+=======================+
0. CONTENTS:
+=======================+

  1. Original modification notes on the conversion of bugzilla 2.11 to
     IssueZilla by Niels Mayer (npm@@collab.net)

  2. Summary notes and notes on database creation subsequent to modifications
     to support multiple vhosts.

+=======================+
1.  ORIGINAL NOTES:
+=======================+
  
  This is bugzilla straight outta CVS as of 9/27/2000.
  
  Edited by NPM to work w/ tigris, qmail, etc
  
  Further edited by NPM replacing most instances of "bugs"-->"issues"
  "a issue" --> "an issue" etc. 
  
  NPM twiddled with query.cgi to lay things out more reasonably, and
  add space for future enhancements/customizations.
  
  NPM Removed bugs db column 'severity' and replaced it with 'issue-type'.
  Severity seems silly and it's confusing/redundant with priority 'P1'-'P5'.
  Some aspects of 'severity' are handled by 'issue-type', e.g.  you
  distinguish between an enhancement, feature, task, defect, or a patch.
  
  --------------------
  
  To do an upgrade against mozilla.org, move all directories 'CVS' to 'CVS.bak',
  e.g. (in tcsh):
  
  | beral-5-.../sandbox/issuezilla> foreach i (`find . -name CVS`)
  | foreach? mv $i $i.bak
  | foreach? end
  
  Then move all 'CVS.mozilla' to 'CVS':
  
  | beral-6-.../sandbox/issuezilla> foreach i (`find . -name CVS.mozilla`)
  | foreach? mv $i `dirname $i`/CVS
  | foreach? end
  
  
  Then to see what files might have changed, since this version was last
  updated, do:
  
  | beral-7-.../sandbox/issuezilla> cvs -qn update
  
  Then you can either do 'cvs update' and be very careful to watch the output
  of cvs, noting any conflicts between the issuezilla edits and mozilla.org's
  edits... (prior to doing 'cvs update' beware of files marked w/ 'C' when
  you do 'cvs -qn update', as they'll definitely create non-working
  conflict-munged code that needs to be hand edited).
  
  --------------------
  
  Note the following files are to be instantiated by a tigris SANDBOX initialization script
  which someone needs to write...
  
  ./data/params.in             ---> ./data/params
  ./localconfig.in	     ---> ./localconfig
  ./20issue-track.conf.in      ---> ./20issue-track.conf

+=======================+
2.[a]  SUMMARY:
+=======================+
  Support for differentiating issuezilla databases on a per-project has been implemented (this superceedes the previous implementation, which differentiated databases by vhost). The file which controls this behavior is a '.in' file - localconfig.in - which is configured at installation.   At install time, the file defines the following values, usually taken from env.sh:
  
      DATABASE_HOST
      DATABASE_PORT
      DATABASE_USER
      DATABASE_PASSWORD
  
  The file also defines IZ_DATABASE_NAME, which may be expanded to include project id depending on the value of the token IZ_MULTIPLE_PROJECT_DATABASES at installation, and defines SANDBOX, which is used solely by the setup script (checksetup.pl) to orient itself before performing its actions.  The following are the translation rules that can apply:
  
  Assume:
  
      - in env.sh, an environmental IZ_DATABASE_NAME set to 'issues' 
      - a project id X
  
  The flag - '$::use_project_id_database' - will be set (via IZ_MULTIPLE_PROJECT_DATABASES) to produce one of two states:
  
      [false] use database named 'issues'
      
      [true] use database named 'issues_X'
      
  Similarly, localconfig controls the definitions of the two other directories that issuezilla uses to store per-db data on the filesystem - 'shadow' and 'data'.  It sets these as follows, using the same flag as above:
  
      [false] 
          $::data_dir    = "data/";
          $::shadow_dir  = "shadow/";
      [true]
          $::data_dir    = "data/$db_name";
          $::shadow_dir  = "shadow/$db_name";
  
  So that if the flag is set to use anything other than the default database for this installation, it segregates data by host.  
  
  NOTE:  these settings control how a the database name is derived AT RUNTIME.  They have essentially nothing to do with the how a database by the (presumed) matching name is created.  That process is covered below in DATABASE CREATION.

+=======================+
2.[b]  DATABASE CREATION:
+=======================+
  Database creation should now be handled automatically through the web interface (via servlet which calls a series of perl scripts, which in turn call the scripts described below) based on the settings described above; nonetheless, it is possible to perform this manually if necessary.  The script which came with bugzilla has been modified so that it can be used to initialize arbitrary databases; if you set the env variable IZ_DATABASE_NAME to the name of the issuezilla database, you run the setup script as follows:
  
  ./checksetup.pl -d $IZ_DATABASE_NAME -u [db_user] -p [db_password]
  
  Where 'dbuser' and 'dbpassword' are for a user with sufficient mysql priviliges to create databases (usually root).  The script will exit if, at a minimum, 'dbuser' is not supplied.  Note that this does NOT set up the DATABASE_USER permissions for the database - just the database itself.  A separate script with identical arguments has been created to automate the updating of permissions, and is called as follows:
  
  ./checkdbuser.pl -d $IZ_DATABASE_NAME -u [db_user] -p [db_password]
  

NOTE:  here, 'dbuser' and 'dbpassword' MUST be a user with privileges to update the mysql:db database, as well as run a 'mysqladmin reload' - usually root.  In all likelihood, if you created a programmatic user to run the first script (checksetup.pl), it will NOT have sufficient mysql privileges to run the second.



@


1.7
log
@Updated readme to reflect current state of database creation and access
@
text
@@


1.7.12.1
log
@Solaris compatibility: Lots of changes:
- Changesand additions to the build files so that the system builds on Solaris.
- Changes to issuezilla so that it works on PERL 5.6.
- Changes to scripts so that they use bash as their interpreter explicitly.
- Changes to search/makeit.in so that the makeit script also runs on Solaris.
Issue number:
Obtained from:
Submitted by:
Reviewed by:
@
text
@d97 2
a98 2
          $::data_dir    = "data/$::db_name";
          $::shadow_dir  = "shadow/$::db_name";
@


1.7.2.1
log
@Changed files to explicitly reference global database vars. - fixes problems
with package qualification in some cases.
@
text
@d97 2
a98 2
          $::data_dir    = "data/$::db_name";
          $::shadow_dir  = "shadow/$::db_name";
@


1.6
log
@make reference to IZ_DATABASE_NAME which will generally be set from
env.sh (required to transform localconfig.in -> localconfig via
configure.pl)
@
text
@d71 1
a71 1
  The support for basing issuezilla databases on vhost has been implemented.  The file which controls this behavior is a '.in' file - localconfig.in - which is configured at installation.   At install time, the file defines the following values, usually taken from env.sh:
d78 1
a78 1
  The file also defines DATABASE_NAME, but this gets translated depending on what a value is set to in localconfig, and defines SANDBOX, which is used solely by the setup script (checksetup.pl) to orient itself before performing its actions.  The following are the translation rules that can apply:
d82 2
a83 2
      - in env.sh, an environmental DATABASE_NAME set to 'tigris' 
      - a host with the name 'www.foo.org'
d85 1
a85 1
  The flag - '$use_hostname' - can be set as follows to produce one of three states:
d87 1
a87 1
      [0] use database named 'tigris_issues'
d89 1
a89 5
          [default] This segregates the db from the default one set up
          by the standard Tigris installation (which contains a legacy
          bugzilla database schema, by default)
          
      [1] use database named 'foo_org_issues'
a90 6
          Will translate requests from any HTTP_HOST *.foo.org
      
      [>1] use database named 'www_foo_org_issues'
          
          Will translate ONLY requests from HTTP_HOST www.foo.org
  
d93 1
a93 1
      [0] 
d96 1
a96 1
      [>0]
d107 1
a107 2
  
  The script which came with bugzilla has been modified so that it can be used to initialize arbitrary databases; if you set the env variable IZ_DATABASE_NAME to the name of the issuezilla database, you run the setup script as follows:
d111 1
a111 1
  Where 'dbuser' and 'dbpassword' are for a user with sufficient mysql priviliges to create databases.  The script will exit if, at a minimum, 'dbuser' is not supplied.  Note that this does NOT set up the DATABASE_USER permissions for the database - just the database itself.  A separate script with identical arguments has been created to automate the updating of permissions, and is called as follows:
@


1.5
log
@Updated the the README to include notes on setup script modifications to
support multiple vhosts.
@
text
@d118 1
a118 1
  The script which came with bugzilla has been modified so that it can be used to initialize arbitrary databases; you run the setup script as follows:
d120 1
a120 1
  ./checksetup.pl -d [databasename] -u [db_user] -p [db_password]
d124 1
a124 1
  ./checkdbuser.pl -d [databasename] -u [db_user] -p [db_password]
@


1.4
log
@added "PATCH" issue type; make "DEFECT" default issue type
@
text
@d1 1
a1 1
Notes on Bugzilla/IssueZilla.
d3 123
a125 1
--------------------
d127 1
a127 1
This is bugzilla straight outta CVS as of 9/27/2000.
a128 1
Edited by NPM to work w/ tigris, qmail, etc
a129 2
Further edited by NPM replacing most instances of "bugs"-->"issues"
"a issue" --> "an issue" etc. 
a130 43
NPM twiddled with query.cgi to lay things out more reasonably, and
add space for future enhancements/customizations.

NPM Removed bugs db column 'severity' and replaced it with 'issue-type'.
Severity seems silly and it's confusing/redundant with priority 'P1'-'P5'.
Some aspects of 'severity' are handled by 'issue-type', e.g.  you
distinguish between an enhancement, feature, task, defect, or a patch.

--------------------

To do an upgrade against mozilla.org, move all directories 'CVS' to 'CVS.bak',
e.g. (in tcsh):

| beral-5-.../sandbox/issuezilla> foreach i (`find . -name CVS`)
| foreach? mv $i $i.bak
| foreach? end

Then move all 'CVS.mozilla' to 'CVS':

| beral-6-.../sandbox/issuezilla> foreach i (`find . -name CVS.mozilla`)
| foreach? mv $i `dirname $i`/CVS
| foreach? end


Then to see what files might have changed, since this version was last
updated, do:

| beral-7-.../sandbox/issuezilla> cvs -qn update

Then you can either do 'cvs update' and be very careful to watch the output
of cvs, noting any conflicts between the issuezilla edits and mozilla.org's
edits... (prior to doing 'cvs update' beware of files marked w/ 'C' when
you do 'cvs -qn update', as they'll definitely create non-working
conflict-munged code that needs to be hand edited).

--------------------

Note the following files are to be instantiated by a tigris SANDBOX initialization script
which someone needs to write...

./data/params.in             ---> ./data/params
./localconfig.in	     ---> ./localconfig
./20issue-track.conf.in      ---> ./20issue-track.conf
@


1.3
log
@*** empty log message ***
@
text
@d18 1
a18 1
distinguish between an enhancement, feature, task, or defect.
@


1.2
log
@*** empty log message ***
@
text
@d23 1
a23 1
e.g. (in tcsh)P:
d39 1
a39 1
| beral-6-.../sandbox/issuezilla> cvs -qn update
d43 3
a45 1
edits... (files marked w/ 'C').
@


1.1
log
@Notes on Bugzilla/IssueZilla.

--------------------

This is bugzilla straight outta CVS as of mid-september 2000.

Edited by NPM to work w/ tigris, qmail, etc

Further edited by NPM replacing most instances of "bugs"-->"issues"
"a issue" --> "an issue" etc.

NPM twiddled with query.cgi to lay things out more reasonably, and
add space for future enhancements/customizations.

NPM Removed bugs db column 'severity' and replaced it with 'issue-type'.
Severity seems silly and it's confusing/redundant with priority 'P1'-'P5'.
Some aspects of 'severity' are handled by 'issue-type', e.g.  you
distinguish between an enhancement, feature, task, or defect.

--------------------

To do an upgrade against mozilla.org, move all directories 'CVS' to 'CVS.bak',
e.g. (in tcsh)P:

| beral-5-.../sandbox/issuezilla> foreach i (`find . -name CVS`)
| foreach? mv $i $i.bak
| foreach? end

Then move all 'CVS.mozilla' to 'CVS':

| beral-6-.../sandbox/issuezilla> foreach i (`find . -name CVS.mozilla`)
| foreach? mv $i `dirname $i`/CVS
| foreach? end


Then to see what files might have changed, since this version was last
updated, do:

| beral-6-.../sandbox/issuezilla> cvs -qn update

Then you can either do 'cvs update' and be very careful to watch the output
of cvs, noting any conflicts between the issuezilla edits and mozilla.org's
edits... (files marked w/ 'C').

--------------------

Note the following files are to be instantiated by a tigris SANDBOX initialization script
which someone needs to write...

./data/params.in             ---> ./data/params
./localconfig.in	     ---> ./localconfig
./20issue-track.conf.in      ---> ./20issue-track.conf
@
text
@d5 1
a5 1
This is bugzilla straight outta CVS as of mid-september 2000.
@

