]> git.ipfire.org Git - thirdparty/bugzilla.git/commitdiff
Patch by (mostly) Bert Driehuis <bert_driehuis@nl.compuware.com> --
authorterry%netscape.com <>
Tue, 22 Sep 1998 06:29:39 +0000 (06:29 +0000)
committerterry%netscape.com <>
Tue, 22 Sep 1998 06:29:39 +0000 (06:29 +0000)
explain a bit about the versioncache file.

README

diff --git a/README b/README
index f7bc7ace564c1e9b65b1c38ec643e47d9c7a557c..dab08e205d514bf38b1dd04fee555a9151da951c 100644 (file)
--- a/README
+++ b/README
@@ -107,3 +107,22 @@ It's a good idea to set up a daily cronjob that does
 This causes email that gets sent to anyone who has a NEW bug that
 hasn't been touched for several days.  For more info, see the
 whinedays and whinemail parameters.
+
+
+6. Modifying your running system
+
+Bugzilla optimizes database lookups by storing all relatively static
+information in the versioncache file, located in the data/
+subdirectory under your installation directory (we said before it
+needs to be writable, right?!)
+
+If you make a change to the structural data in your database (the
+versions table for example), or to the "constants" encoded in
+defparams.pl, you will need to remove the cached content from the data
+directory (by doing a "rm data/versioncache"), or your changes won't
+show up!
+
+That file gets automatically regenerated whenever it's more than an
+hour old, so Bugzilla will eventually notice your changes by itself,
+but generally you want it to notice right away, so that you can test
+things.