Bugzilla:FAQ:Administrative Questions: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
(Replaced content with 'See Bugzilla:FAQ#Administrative_Questions.')
 
(6 intermediate revisions by 5 users not shown)
Line 1: Line 1:
=[[Bugzilla:FAQ:Administrative_Questions|Administrative Questions]]=
See [[Bugzilla:FAQ#Administrative_Questions]].
==Does Bugzilla provide record locking when there is simultaneous access to the same bug? Does the second person get a notice that the bug is in use or how are they notified?==
Bugzilla does not lock records.
It provides mid-air collision detection --
which means that it warns a user when a commit is about to conflict
with commits recently made by another user,
and offers the second user a choice of options to deal with the conflict.
 
==Can users be on the system while a backup is in progress?==
Yes, but commits to the database must wait until the tables are unlocked.
Bugzilla databases are typically very small,
and backups routinely take less than a minute.
If your database is larger,
you may want to look into alternate backup techniques,
such as database replication, or backing up from a read-only mirror.
(Read up on these in the MySQL docs on the MySQL site.)
 
== How can I update the code and the database using CVS?==
#Make a backup of both your Bugzilla directory and the database. For the Bugzilla directory this is as easy as doing cp -rp bugzilla bugzilla.bak. For the database, there's a number of options - see the MySQL docs and pick the one that fits you best (the easiest is to just make a physical copy of the database on the disk, but you have to have the database server shut down to do that without risking dataloss).
#Make the Bugzilla directory your current directory.
#Use '''cvs -q update -AdP''' if you want to update to the tip or '''cvs -q update -dP -rTAGNAME''' if you want a specific version (in that case you'll have to replace TAGNAME with a CVS tag name such as BUGZILLA-2_16_5).
#*If you've made no local changes, this should be very clean. If you have made local changes, then watch the cvs output for C results. If you get any lines that start with a C it means there were conflicts between your local changes and what's in CVS. You'll need to fix those manually before continuing.
#After resolving any conflicts that the cvs update operation generated, running ./checksetup.pl will take care of updating the database for you as well as any other changes required for the new version to operate.
#*Once you run checksetup.pl, the only way to go back is to restore the database backups. You can't "downgrade" the system cleanly under most circumstances.
 
See also the instructions in [http://www.bugzilla.org/docs/tip/html/upgrading.html#upgrade-cvs Section3.12.2.1].
 
== How do I make it so that bugs can have an UNCONFIRMED status?==
To use the UNCONFIRMED status,
you must have the 'usevotes' parameter set to "On".
You must then visit the editproducts.cgi page and set the
" Number of votes a bug in this product needs to automatically get
out of the UNCONFIRMED state" to be a non-zero number.
(You will have to do this for each product that wants to use the UNCONFIRMED state.)
If you do not actually want users to be able to vote for bugs entered
against this product, leave the "Maximum votes per person" value at '0'.
 
There is work being done to decouple the UNCONFIRMED state
from the 'usevotes' parameter for future versions of Bugzilla.
Follow the discussion and progress at [https://bugzilla.mozilla.org/show_bug.cgi?id=162060 bug 162060].
 
== How do I move a Bugzilla installation from one machine to another?==
Use mysqldump to make a backup of the bugs database.
For a typical Bugzilla setup, such a command might look like this:
/usr/bin/mysqldump -u(username) -p(password) --database bugs > bugzilla-backup.txt
See the
[http://dev.mysql.com/doc/mysql/en/mysqldump.html mysqldump documentation]
for more information on using the tool,
including how to restore your copy onto the destination machine.
*Depending on the size of your database, and the power of your machine, the mysqldump command could be running long enough that the password would be visible to someone using the ps command. If you are on a multi-user machine, and this is a concern to you, create an entry in the file ~/.my.cnf that looks like this:
[mysqldump]
user=bugs
password=mypassword
and then leave the 'user' and 'password' params out of the command line.
 
On your new machine, follow the instructions found in
[http://www.bugzilla.org/docs/tip/html/installing-bugzilla.html Chapter 2]
as far as setting up the physical environment of the new machine with perl,
webserver, modules, etc.
Having done that, you can either:
copy your entire Bugzilla directory from the old machine to a new one
(if you want to keep your existing code and modifications),
or download a newer version (if you are planning to upgrade at the same time).
Even if you are upgrading to clean code,
you will still want to bring over the localconfig file,
and the data directory from the old machine,
as they contain configuration information
that you probably won't want to re-create.
 
*If the location or port number of your SQL server changed as part of the move, you'll need to update the appropriate variables in localconfig before taking the next step.
 
Once you have your code in place, and your database has been restored
from the backup you made in step 1, run checksetup.pl.
This will upgrade your database (if necessary), rebuild your templates, etc.
 
[[category:Bugzilla]]
{{Navigation Bugzilla FAQ}}

Latest revision as of 13:26, 19 March 2010

See Bugzilla:FAQ#Administrative_Questions.

Retrieved from "https://wiki.mozilla.org/index.php?title=Bugzilla:FAQ:Administrative_Questions&oldid=209824"