WIP

git-svn-id: svn://10.0.0.236/trunk@265711 18797224-902f-48f8-a5cc-f745e15eee43

mozilla/webtools/bugzilla/.bzrrev

@@ -1 +1 @@
-9239
+9240

mozilla/webtools/bugzilla/.gitrev

@@ -1 +1 @@
-a0646ff7d1452e86361aec4e463f0d9ec2135bfe
+9aa4b8083d1bacd6ca24bfd7f4c413827236684e

mozilla/webtools/bugzilla/docs/en/rst/administering/parameters.rst

@@ -182,7 +182,7 @@ emailregexp
     used for login names. The default attempts to match fully
     qualified email addresses (i.e. 'user\@example.com') in a slightly
     more restrictive way than what is allowed in RFC 2822.
-    Another popular value to put here is :paramval:``^[^@]+`, which means 'local usernames, no @ allowed.' 
+    Another popular value to put here is :paramval:`^[^@]+`, which means 'local usernames, no @ allowed.' 
 
 emailregexpdesc
     This description is shown to the user to explain which email addresses are allowed by the :param:`emailregexp` param. 
@@ -406,7 +406,7 @@ timetrackinggroup
 querysharegroup
     The name of the group of users who are allowed to share saved
     searches with one another. For more information on using
-    saved searches, see :ref:`savedsearches`.
+    saved searches, see :ref:`saved-searches`.
 
 comment_taggers_group
     The name of the group of users who can tag comment. Setting this to empty disables comment tagging.

mozilla/webtools/bugzilla/docs/en/rst/customizing/templates.rst

@@ -55,7 +55,7 @@ modifications, and the method you plan to use to upgrade Bugzilla.
    not exist by default and must be created if you want to use it.)
 
 #. You can use the hooks built into many of the templates to add or modify
-   the UI from an :ref:`extension`. Hooks generally don't go away and have
+   the UI from an :ref:`extension <extensions>`. Hooks generally don't go away and have
    a stable interface. 
 
 The third method is the best if there are hooks in the appropriate places.

mozilla/webtools/bugzilla/docs/en/rst/installing/iis.rst

@@ -63,6 +63,6 @@ doesn't use any of them.
 Also, and this can't be stressed enough, make sure that files
 such as :file:`localconfig` and your
 :file:`data` directory are
-secured as described in :ref:`security-webserver-access`.
+secured.
 
 XXX See also https://wiki.mozilla.org/Installing_under_IIS_7.5

mozilla/webtools/bugzilla/docs/en/rst/installing/moving.rst

@@ -15,16 +15,9 @@ things should still work.
 
 1. Shut down your Bugzilla by loading the front page, going to
    :guilabel:`Administration` | :guilabel:`Parameters` | :guilabel:`General`
-   and putting some text into the :param:`shutdownhtml` parameter.
+   and putting some explanatory text into the :param:`shutdownhtml` parameter.
 
-2. Make a backup of the bugs database. For a typical Bugzilla setup using
-   MySQL, such a command might look like this:
-
-   :command:`mysqldump -u<username> -p bugs > bugzilla-backup.sql`
-
-   See the
-   `mysqldump documentation <http://dev.mysql.com/doc/mysql/en/mysqldump.html>`_
-   for more information on :file:`mysqldump`.
+2. Make a :ref:`backup <backups>` of the bugs database.
 
 3. On your new machine, install Bugzilla using the instructions at
    :ref:`installing`. Look at the old machine if you need to know what values
@@ -41,24 +34,25 @@ things should still work.
    one, update the :param:`urlbase` parameter in :file:`data/params.json`
    using a text editor.
 
-7. Copy the database backup file :file:`bugzilla-backup.sql` file from your
-   old server to the new one.
+7. Copy the database backup file from your old server to the new one.
 
-8. Create an empty ``bugs`` database on the new server:
+8. Create an empty ``bugs`` database on the new server. For MySQL, that would
+   look like this:
 
    :command:`mysql -u root -p -e "CREATE DATABASE bugs DEFAULT CHARACTER SET utf8;"`
 
-9. Import your :file:`bugzilla-backup.sql` file into your new ``bugs`` database:
+9. Import your backup file into your new ``bugs`` database. Again, for MySQL:
 
-   :command:`mysql -u root -p bugs < bugzilla-backup.sql`
+   :command:`mysql -u root -p bugs < $BACKUP_FILE_NAME`
 
    If you get an error about "packet too large" or "MySQL server has gone
    away", you need to adjust the ``max_allowed_packet`` setting in
-   your :file:`my.cnf` file (usually :file:`/etc/my.cnf`) file to be larger
-   than the largest attachment ever added to your Bugzilla.
+   your :file:`my.cnf` file (usually :file:`/etc/my.cnf`) file to match or
+   exceed the value configured in the same file in your old version of MySQL.
 
-   If there are *any* errors during this step, you have to drop the
-   database, create it again using the step above, and do the import again.
+   If there are *any* errors during this step, you have to work out what
+   went wrong, and then drop the database, create it again using the step
+   above, and run the import again.
 
 10. Run :file:`checksetup.pl` to make sure all is OK.
     (Unless you are using a newer version of Bugzilla on your new server, this
@@ -66,6 +60,7 @@ things should still work.
 
     :command:`./checksetup.pl`
 
-11. Activate your new Bugzilla by loading the front page, going to
-    :guilabel:`Administration` | :guilabel:`Parameters` | :guilabel:`General`
-    and removing the text from the :param:`shutdownhtml` parameter.
+11. Activate your new Bugzilla by loading the front page on the new server,
+    going to :guilabel:`Administration` | :guilabel:`Parameters` |
+    :guilabel:`General` and removing the text from the :param:`shutdownhtml`
+    parameter.

mozilla/webtools/bugzilla/docs/en/rst/upgrading/overview.rst

@@ -11,13 +11,13 @@ the method by which you obtain the code along the way.
    upgraded Bugzilla. If you wish to revert to the old Bugzilla
    version for any reason, you will have to restore your system
    from a backup. Those with critical data or large installations may wish
-   to trial the upgrade on a development server first, using a copy of the
+   to test the upgrade on a development server first, using a copy of the
    production data and configuration.
  
 Bugzilla uses the Git version control system to store its code. A modern Bugzilla
 installation consists of a checkout of a stable version of the code from our
 Git repository. This makes upgrading much easier. If this is
-true of you, see :ref:`upgrading-with-git`.
+true of your installation, see :ref:`upgrading-with-git`.
 
 Before Git, we used to use Bazaar and, before that, CVS. If your installation
 of Bugzilla consists of a checkout from one of those two systems, you need to