ebl fix display_log to use LogId instead of Time for order

[bacula/bacula] / regress / README

diff --git a/regress/README b/regress/README
index 7a8f2fed980d7de061d07a4d21012fcd3fd2b18a..040f87fc11a1878d5bf8e9646c453a81fe8da620 100644 (file)
--- a/regress/README
+++ b/regress/README
@@ -3,6 +3,15 @@
 
 This is Bacula's regression script directory.
 
 
 This is Bacula's regression script directory.
 

+!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+Warning!!!! Make sure not to run it on the same system 
+with your production Catalog because the tables will all
+be cleared. You can run it on the your production system
+if you use a different database. E.g. if your production
+system uses MySQL, you can use SQLite here.
+!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+

 To set it up, create your personal configuration file, by
 copying prototype.conf to xxx.conf or simply editing prototype.conf
 directly.
 To set it up, create your personal configuration file, by
 copying prototype.conf to xxx.conf or simply editing prototype.conf
 directly.


@@ -12,8 +21,14 @@ for the variables that are in that file.  If you want to see
 a real example, look at kern.conf, but please don't use my
 email address!
 
 a real example, look at kern.conf, but please don't use my
 email address!
 

-Make sure that depkgs is pre-built if it isn't 
-already: (cd your-depkgs; make sqlite).
+If you are using SQLite, make sure that depkgs is pre-built if it
+isn't already: (cd your-depkgs; make sqlite).
+
+Note, if you use any database other than SQLite, be sure it is not              
+your production database because Bacula will delete all the tables
+and recreate them.  With SQLite, a new different database is created,
+so it will not affect your production system.
+

 Using the .conf file, you can now select between any Catalog type:
 SQLite, SQLite3, MySQL, or PostgreSQL.  Be aware, however, if you
 use an installed database on a production server, running these
 Using the .conf file, you can now select between any Catalog type:
 SQLite, SQLite3, MySQL, or PostgreSQL.  Be aware, however, if you
 use an installed database on a production server, running these


@@ -38,30 +53,29 @@ a resonable run.  Each test is totally independent of any other
 test. Aside from the required "make setup", each test is totally
 self-initalizing and should clean up after itself.
 
 test. Aside from the required "make setup", each test is totally
 self-initalizing and should clean up after itself.
 

-Not all the tests yet report OK.  This is simply because there are
-some spurious differences that I haven't yet taken the time to
-eliminate.  The working scrips as of 24 Apr 03 are (this is
-way out of date!):
-
-backup-bacula-test
-sparse-test
-compressed-test
-sparse-compressed-test
-two-jobs-test
-wierd-files-test
-verify-vol-test
-
-The tests expect you to execute them from the main regress 
+All the tests expect you to execute them from the main regress 

 directory!               
 
 You can run all the disk based tests by doing:
 
   ./do_file
 
 directory!               
 
 You can run all the disk based tests by doing:
 
   ./do_file
 

+The disk based tests are totally separate from any production
+system, provided you have configured the database appropriately     
+as noted above.
+

 You can run all the disk and most of the tape tests by doing:
 
   ./do_all
 
 You can run all the disk and most of the tape tests by doing:
 
   ./do_all
 

+======== Important !!! ============
+When running the tape tests, Bacula will write on any tape that
+is in the tape drive that you have configured.  If it is a production
+Bacula tape, it will be destroyed.  If you have configured an Autochanger,
+Bacula will write on the tapes in slots 1 and 2 thus destroying any
+information on those tapes, even if they are Bacula production tapes.
+=================================== 
+

 Each of the above calls one or more scripts. By looking at the
 scripts available in this directory, you can see that there are a number
 of options for running tests.
 Each of the above calls one or more scripts. By looking at the
 scripts available in this directory, you can see that there are a number
 of options for running tests.


@@ -102,6 +116,11 @@ conf files, and you do not need a new copy of the source, you can simply do:
 
 Debugging failed tests:
 The simplest thing to do is to edit tests/xxxx where xxxx is the name of
 
 Debugging failed tests:
 The simplest thing to do is to edit tests/xxxx where xxxx is the name of

-the test, and change the line "debug=0" to "debug=1".  If the test has
+the test, and change the line "set_debug 0" to "set_debug 1".  If the test has

 not been updated to have the debug variable, please notify Kern, and I
 will be happy to fix it -- I am upgrading them one at a time.
 not been updated to have the debug variable, please notify Kern, and I
 will be happy to fix it -- I am upgrading them one at a time.

+
+Also, if you run from time to time on a computer that is not connected
+to the network, please be sure that "hostname" is set to "localhost",
+otherwise, your tests may fail because the hostname used by Bacula's
+./configure cannot be properly resolved.