List:Commits« Previous MessageNext Message »
From:paul.dubois Date:July 12 2010 8:32pm
Subject:svn commit - mysqldoc@docsrva: r21675 - in trunk: . dynamic-docs/changelog dynamic-docs/glossary innodb-plugin-1.1 mysqldoc-guide refman-4.1 refman-5....
View as plain text  
Author: paul
Date: 2010-07-12 22:32:30 +0200 (Mon, 12 Jul 2010)
New Revision: 21675

Log:
 r61077@frost:  paul | 2010-07-12 14:46:17 -0500
 Oracle style guideline: afterwards -> afterward; backwards -> backward


Modified:
   trunk/dynamic-docs/changelog/monitor.xml
   trunk/dynamic-docs/changelog/mysqld-1.xml
   trunk/dynamic-docs/changelog/mysqld.xml
   trunk/dynamic-docs/glossary/innodb.xml
   trunk/innodb-plugin-1.1/innodb-performance.xml
   trunk/innodb-plugin-1.1/plugin.ent
   trunk/mysqldoc-guide/styleguide.xml
   trunk/refman-4.1/mysql-cluster-multi-computer.xml
   trunk/refman-4.1/mysql-cluster-overview.xml
   trunk/refman-5.0/installing-updowngrade.xml
   trunk/refman-5.0/mysql-cluster-multi-computer.xml
   trunk/refman-5.0/mysql-cluster-overview.xml
   trunk/refman-5.0/replication-notes.xml
   trunk/refman-5.0/sql-syntax-data-definition.xml
   trunk/refman-5.1/dba-log-files.xml
   trunk/refman-5.1/information-schema.xml
   trunk/refman-5.1/mysql-cluster-management.xml
   trunk/refman-5.1/mysql-cluster-multi-computer.xml
   trunk/refman-5.1/mysql-cluster-overview.xml
   trunk/refman-5.1/replication-notes.xml
   trunk/refman-5.5/dba-log-files.xml
   trunk/refman-5.5/replication-notes.xml
   trunk/refman-6.0/dba-log-files.xml
   trunk/refman-6.0/replication-notes.xml
   trunk/refman-common/news-cluster.xml
   trunk/refman-common/news-innodb.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:40730
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:61076
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
   + 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:40730
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:61077
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546


Modified: trunk/dynamic-docs/changelog/monitor.xml
===================================================================
--- trunk/dynamic-docs/changelog/monitor.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/dynamic-docs/changelog/monitor.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 638 bytes

@@ -151,7 +151,7 @@
 
       <para>
         When using &merlin_agent;, if the current configured time went
-        backwards (for example during time correction), then the
+        backward (for example, during time correction), the
         &merlin_agent; would stop reporting data and induce a high load
         on the machine running &merlin_agent;
       </para>


Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 581 bytes

@@ -8070,7 +8070,7 @@
       <para>
         If the cluster crashed during the execution of a
         <literal role="stmt">CREATE LOGFILE GROUP</literal> statement,
-        the cluster could not be restarted afterwards.
+        the cluster could not be restarted afterward.
       </para>
 
     </message>


Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/dynamic-docs/changelog/mysqld.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 6, Lines Added: 6, Lines Deleted: 6; 2362 bytes

@@ -1344,7 +1344,7 @@
           to include <literal>&apos;</literal> characters in
           <literal>PARTITION</literal> options must still be removed by
           deleting the corresponding <filename>.frm</filename> files and
-          re-creating them afterwards.
+          re-creating them afterward.
         </para>
       </note>
 

@@ -16241,7 +16241,7 @@
         and encounters a row in the binary log that is written in
         <literal>ROW</literal> logging format. In that case, the slave
         switches to row-based replication temporarily for that event,
-        and switches back to the previous format afterwards.
+        and switches back to the previous format afterward.
       </para>
 
     </message>

@@ -81008,7 +81008,7 @@
             <para>
               Alternatively, you can dump the table using
               <command>mysqldump</command> prior to upgrading and reload
-              it afterwards with <literal role="stmt">LOAD
+              it afterward with <literal role="stmt">LOAD
               DATA</literal>.
             </para>
           </listitem>

@@ -89417,7 +89417,7 @@
         version and scheduled events have been used, the upgrade
         utilities do not accomodate changes in event-related system
         tables. As a workaround, you can dump events before the upgrade,
-        then restore them from the dump afterwards. This issue was fixed
+        then restore them from the dump afterward. This issue was fixed
         in MySQL 5.1.20.
       </para>
 

@@ -91511,7 +91511,7 @@
         sometimes corrupted table resolution for statements which were
         prepared before the <literal role="stmt" condition="flush">FLUSH
         TABLES</literal> but which were being executed repeatedly
-        afterwards.
+        afterward.
       </para>
 
     </message>

@@ -119048,7 +119048,7 @@
       <para>
         <literal>MYSQL_STMT</literal> objects were not preserved
         following a connection reset. Attempting to operate on them
-        afterwards caused the server to crash.
+        afterward caused the server to crash.
       </para>
 
     </message>


Modified: trunk/dynamic-docs/glossary/innodb.xml
===================================================================
--- trunk/dynamic-docs/glossary/innodb.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/dynamic-docs/glossary/innodb.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 738 bytes

@@ -1807,7 +1807,7 @@
         data transfer operations, consider doing operations such as
         <literal>ALTER TABLE ... ENGINE=INNODB</literal> or
         <literal>INSERT INTO ... SELECT * FROM ...</literal> without any
-        secondary indexes in place, and creating the indexes afterwards.
+        secondary indexes in place, and creating the indexes afterward.
       </para>
       <para>
         Even if you do not use the InnoDB Plugin as your primary storage


Modified: trunk/innodb-plugin-1.1/innodb-performance.xml
===================================================================
--- trunk/innodb-plugin-1.1/innodb-performance.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/innodb-plugin-1.1/innodb-performance.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 616 bytes

@@ -1193,7 +1193,7 @@
       The goal is to make sure that frequently accessed
       (<quote>hot</quote>) pages remain in the buffer cache, even as
       read-ahead and full table scans bring new blocks in that might or
-      might not be accessed afterwards.
+      might not be accessed afterward.
     </para>
 
     <para>


Modified: trunk/innodb-plugin-1.1/plugin.ent
===================================================================
--- trunk/innodb-plugin-1.1/plugin.ent	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/innodb-plugin-1.1/plugin.ent	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 4638 bytes

@@ -157,7 +157,7 @@
 
 <!ENTITY glos_full_table_scan "<glossentry id='glos_full_table_scan'><glossterm>full table scan</glossterm>&#10;<indexterm significance='preferred'><primary>full table scan</primary></indexterm>&#10;<glossdef>&#10;<para>&#10;An operation that requires reading the entire contents of a table, rather than&#10;just selected portions using an index.&#10;Typically performed either with small lookup tables, or in data warehousing&#10;situations with large tables where all available data is aggregated and analyzed.&#10;How frequently these operations occur, and the sizes of the tables&#10;relative to available memory, have implications for the algorithms used in&#10;query optimization and managing the buffer pool.&#10;</para>&#10;<para>&#10;The purpose of <emphasis role='bold'>indexes</emphasis> is to allow lookups for specific values or&#10;ranges of values within a large table, thus avoiding full table scans&#10;when practical.&#10;</para>&#10;<glossseealso otherterm='glos_buffer!
 _pool' />&#10;&#10;<glossseealso otherterm='glos_index' />&#10;</glossdef>&#10;</glossentry>&#10;">
 
-<!ENTITY glos_fast_index_creation "<glossentry id='glos_fast_index_creation'><glossterm>fast index creation</glossterm>&#10;<indexterm significance='preferred'><primary>fast index creation</primary></indexterm>&#10;<glossdef>&#10;<para>&#10;A capability first introduced in the InnoDB Plugin, that speeds up&#10;creation of secondary indexes by avoiding the need to completely rewrite the associated table.&#10;The speedup applies to dropping secondary indexes also.&#10;</para>&#10;<para>&#10;Because index maintenance can add performance overhead to many data transfer&#10;operations, consider doing operations such as <literal>ALTER TABLE ... ENGINE=INNODB</literal>&#10;or <literal>INSERT INTO ... SELECT * FROM ...</literal>&#10;without any secondary indexes in place, and creating the indexes afterwards.&#10;</para>&#10;<para>&#10;Even if you do not use the InnoDB Plugin as your primary storage engine, you&#10;can take advantage of this capability by enabling the Plugin temporar!
 ily,&#10;just to create or drop indexes, and then switch back to the built-in&#10;InnoDB storage engine for normal use.&#10;</para>&#10;<glossseealso otherterm='glos_index' />&#10;<glossseealso otherterm='glos_secondary_index' />&#10;</glossdef>&#10;</glossentry>&#10;">
+<!ENTITY glos_fast_index_creation "<glossentry id='glos_fast_index_creation'><glossterm>fast index creation</glossterm>&#10;<indexterm significance='preferred'><primary>fast index creation</primary></indexterm>&#10;<glossdef>&#10;<para>&#10;A capability first introduced in the InnoDB Plugin, that speeds up&#10;creation of secondary indexes by avoiding the need to completely rewrite the associated table.&#10;The speedup applies to dropping secondary indexes also.&#10;</para>&#10;<para>&#10;Because index maintenance can add performance overhead to many data transfer&#10;operations, consider doing operations such as <literal>ALTER TABLE ... ENGINE=INNODB</literal>&#10;or <literal>INSERT INTO ... SELECT * FROM ...</literal>&#10;without any secondary indexes in place, and creating the indexes afterward.&#10;</para>&#10;<para>&#10;Even if you do not use the InnoDB Plugin as your primary storage engine, you&#10;can take advantage of this capability by enabling the Plugin temporari!
 ly,&#10;just to create or drop indexes, and then switch back to the built-in&#10;InnoDB storage engine for normal use.&#10;</para>&#10;<glossseealso otherterm='glos_index' />&#10;<glossseealso otherterm='glos_secondary_index' />&#10;</glossdef>&#10;</glossentry>&#10;">
 
 <!ENTITY glos_fast_shutdown "<glossentry id='glos_fast_shutdown'><glossterm>fast shutdown</glossterm>&#10;<indexterm significance='preferred'><primary>fast shutdown</primary></indexterm>&#10;<glossdef>&#10;<para>&#10;A shutdown procedure that is required before installation of the InnoDB Plugin.&#10;From the MySQL command line, issue the following&#10;command before performing the shutdown:&#10;<programlisting>SET GLOBAL innodb_fast_shutdown=0;</programlisting>&#10;To make this type of shutdown the default, specify by the configuration parameter&#10;<literal>innodb_fast_shutdown=0</literal>.&#10;</para>&#10;<glossseealso otherterm='glos_slow_shutdown' />&#10;<glossseealso otherterm='glos_shutdown' />&#10;</glossdef>&#10;</glossentry>&#10;">
 


Modified: trunk/mysqldoc-guide/styleguide.xml
===================================================================
--- trunk/mysqldoc-guide/styleguide.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/mysqldoc-guide/styleguide.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 0; 504 bytes

@@ -1329,6 +1329,12 @@
 
       <listitem>
         <para>
+          afterward, not afterwards
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           a lot requires two words; alot is wrong
         </para>
       </listitem>


Modified: trunk/refman-4.1/mysql-cluster-multi-computer.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-multi-computer.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-4.1/mysql-cluster-multi-computer.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 754 bytes

@@ -1753,7 +1753,7 @@
                   <para>
                     Use <command>mysqldump</command> (see
                     <xref linkend="mysqldump"/>) to create a backup
-                    prior to the upgrade; afterwards, restore the dump
+                    prior to the upgrade; afterward, restore the dump
                     using
                     <literal role="stmt" condition="load-data">LOAD DATA
                     INFILE</literal>.


Modified: trunk/refman-4.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-overview.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-4.1/mysql-cluster-overview.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 680 bytes

@@ -1551,7 +1551,7 @@
                 <literal role="type">BLOB</literal> or
                 <literal role="type">TEXT</literal> columns, or, in
                 cases where such queries are not avoidable, by
-                committing transactions as soon as possible afterwards.
+                committing transactions as soon as possible afterward.
               </para>
 
               <para>


Modified: trunk/refman-5.0/installing-updowngrade.xml
===================================================================
--- trunk/refman-5.0/installing-updowngrade.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/installing-updowngrade.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 621 bytes

@@ -590,7 +590,7 @@
             This problem does not occur (and thus these two steps are
             not required) for tables upgraded using the recommended
             procedure of dumping tables prior to the upgrade and
-            reloading them afterwards.
+            reloading them afterward.
           </para>
 
           <note>


Modified: trunk/refman-5.0/mysql-cluster-multi-computer.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-multi-computer.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/mysql-cluster-multi-computer.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 754 bytes

@@ -1740,7 +1740,7 @@
                   <para>
                     Use <command>mysqldump</command> (see
                     <xref linkend="mysqldump"/>) to create a backup
-                    prior to the upgrade; afterwards, restore the dump
+                    prior to the upgrade; afterward, restore the dump
                     using
                     <literal role="stmt" condition="load-data">LOAD DATA
                     INFILE</literal>.


Modified: trunk/refman-5.0/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-overview.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/mysql-cluster-overview.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 680 bytes

@@ -1711,7 +1711,7 @@
                 <literal role="type">BLOB</literal> or
                 <literal role="type">TEXT</literal> columns, or, in
                 cases where such queries are not avoidable, by
-                committing transactions as soon as possible afterwards.
+                committing transactions as soon as possible afterward.
               </para>
 
               <para>


Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/replication-notes.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 763 bytes

@@ -945,7 +945,7 @@
         <literal role="stmt">REPAIR TABLE</literal> to repair it, you
         should first stop replication (if it is still running) before
         using <literal role="stmt">REPAIR TABLE</literal>, then
-        afterwards compare the master&apos;s and slave&apos;s copies of
+        afterward compare the master&apos;s and slave&apos;s copies of
         the table and be prepared to correct any discrepancies manually,
         before restarting replication.
       </para>


Modified: trunk/refman-5.0/sql-syntax-data-definition.xml
===================================================================
--- trunk/refman-5.0/sql-syntax-data-definition.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/sql-syntax-data-definition.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1187 bytes

@@ -5963,7 +5963,7 @@
         (<literal><replaceable>table_name</replaceable>.<replaceable>trigger_name</replaceable></literal>).
         When upgrading from a previous version of MySQL 5.0 to MySQL
         5.0.10 or newer, you must drop all triggers <emphasis>before
-        upgrading</emphasis> and re-create them afterwards, or else
+        upgrading</emphasis> and re-create them afterward, or else
         <literal role="stmt">DROP TRIGGER</literal> does not work after
         the upgrade. See
         <xref linkend="upgrading-from-previous-series"/>, for a

@@ -5976,7 +5976,7 @@
       dropped following a downgrade to MySQL 5.0.15 or earlier. If you
       wish to perform such a downgrade, you must also in this case drop
       all triggers <emphasis>prior to</emphasis> the downgrade, and then
-      re-create them afterwards.
+      re-create them afterward.
     </para>
 
     <para>


Modified: trunk/refman-5.1/dba-log-files.xml
===================================================================
--- trunk/refman-5.1/dba-log-files.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/dba-log-files.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 639 bytes

@@ -1473,7 +1473,7 @@
         and encounters an event in the binary log that is written in
         <literal>ROW</literal> logging format. In that case, the slave
         switches to row-based replication temporarily for that event,
-        and switches back to the previous format afterwards.
+        and switches back to the previous format afterward.
       </para>
 
       <para>


Modified: trunk/refman-5.1/information-schema.xml
===================================================================
--- trunk/refman-5.1/information-schema.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/information-schema.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 605 bytes

@@ -5572,7 +5572,7 @@
         <para>
           If you create a MySQL Cluster Disk Data table and then insert
           some rows into it, you can see approximately how much space
-          remains for undo logging afterwards, for example:
+          remains for undo logging afterward, for example:
         </para>
 
 <programlisting>


Modified: trunk/refman-5.1/mysql-cluster-management.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-management.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/mysql-cluster-management.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 689 bytes

@@ -9289,7 +9289,7 @@
         For each column, this table shows the name, data type, and a
         brief description of each <literal>ndbinfo.pools</literal>
         column (as it appeared prior to MySQL Cluster NDB 7.1.3).
-        Additional information can be found in the notes afterwards.
+        Additional information can be found in the notes afterward.
       </para>
 
       <informaltable>


Modified: trunk/refman-5.1/mysql-cluster-multi-computer.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-multi-computer.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/mysql-cluster-multi-computer.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 754 bytes

@@ -3062,7 +3062,7 @@
                   <para>
                     Use <command>mysqldump</command> (see
                     <xref linkend="mysqldump"/>) to create a backup
-                    prior to the upgrade; afterwards, restore the dump
+                    prior to the upgrade; afterward, restore the dump
                     using
                     <literal role="stmt" condition="load-data">LOAD DATA
                     INFILE</literal>.


Modified: trunk/refman-5.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-overview.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/mysql-cluster-overview.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 697 bytes

@@ -4945,7 +4945,7 @@
                 that retrieve <literal role="type">BLOB</literal> or
                 <literal role="type">TEXT</literal> columns, or, in
                 cases where such queries are not avoidable, by
-                committing transactions as soon as possible afterwards.
+                committing transactions as soon as possible afterward.
               </para>
             </listitem>
 


Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/replication-notes.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1192 bytes

@@ -1688,7 +1688,7 @@
           disable the Event Scheduler on the slave (using <literal>SET
           GLOBAL event_scheduler = OFF;</literal>), run the
           <literal role="stmt">UPDATE</literal>, restart the server,
-          then re-enable the Event Scheduler afterwards (using
+          then re-enable the Event Scheduler afterward (using
           <literal>SET GLOBAL event_scheduler = ON;</literal>).
         </para>
 

@@ -2216,7 +2216,7 @@
         <literal role="stmt">REPAIR TABLE</literal> to repair it, you
         should first stop replication (if it is still running) before
         using <literal role="stmt">REPAIR TABLE</literal>, then
-        afterwards compare the master&apos;s and slave&apos;s copies of
+        afterward compare the master&apos;s and slave&apos;s copies of
         the table and be prepared to correct any discrepancies manually,
         before restarting replication.
       </para>


Modified: trunk/refman-5.5/dba-log-files.xml
===================================================================
--- trunk/refman-5.5/dba-log-files.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.5/dba-log-files.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 639 bytes

@@ -1293,7 +1293,7 @@
         and encounters an event in the binary log that is written in
         <literal>ROW</literal> logging format. In that case, the slave
         switches to row-based replication temporarily for that event,
-        and switches back to the previous format afterwards.
+        and switches back to the previous format afterward.
       </para>
 
       <para>


Modified: trunk/refman-5.5/replication-notes.xml
===================================================================
--- trunk/refman-5.5/replication-notes.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.5/replication-notes.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1192 bytes

@@ -1621,7 +1621,7 @@
           disable the Event Scheduler on the slave (using <literal>SET
           GLOBAL event_scheduler = OFF;</literal>), run the
           <literal role="stmt">UPDATE</literal>, restart the server,
-          then re-enable the Event Scheduler afterwards (using
+          then re-enable the Event Scheduler afterward (using
           <literal>SET GLOBAL event_scheduler = ON;</literal>).
         </para>
 

@@ -2131,7 +2131,7 @@
         <literal role="stmt">REPAIR TABLE</literal> to repair it, you
         should first stop replication (if it is still running) before
         using <literal role="stmt">REPAIR TABLE</literal>, then
-        afterwards compare the master&apos;s and slave&apos;s copies of
+        afterward compare the master&apos;s and slave&apos;s copies of
         the table and be prepared to correct any discrepancies manually,
         before restarting replication.
       </para>


Modified: trunk/refman-6.0/dba-log-files.xml
===================================================================
--- trunk/refman-6.0/dba-log-files.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-6.0/dba-log-files.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 639 bytes

@@ -1337,7 +1337,7 @@
         and encounters an event in the binary log that is written in
         <literal>ROW</literal> logging format. In that case, the slave
         switches to row-based replication temporarily for that event,
-        and switches back to the previous format afterwards.
+        and switches back to the previous format afterward.
       </para>
 
       <para>


Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-6.0/replication-notes.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1192 bytes

@@ -1573,7 +1573,7 @@
           disable the Event Scheduler on the slave (using <literal>SET
           GLOBAL event_scheduler = OFF;</literal>), run the
           <literal role="stmt">UPDATE</literal>, restart the server,
-          then re-enable the Event Scheduler afterwards (using
+          then re-enable the Event Scheduler afterward (using
           <literal>SET GLOBAL event_scheduler = ON;</literal>).
         </para>
 

@@ -2029,7 +2029,7 @@
         <literal role="stmt">REPAIR TABLE</literal> to repair it, you
         should first stop replication (if it is still running) before
         using <literal role="stmt">REPAIR TABLE</literal>, then
-        afterwards compare the master&apos;s and slave&apos;s copies of
+        afterward compare the master&apos;s and slave&apos;s copies of
         the table and be prepared to correct any discrepancies manually,
         before restarting replication.
       </para>


Modified: trunk/refman-common/news-cluster.xml
===================================================================
--- trunk/refman-common/news-cluster.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-common/news-cluster.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 590 bytes

@@ -7,7 +7,7 @@
 ]>
 <!--
 The Cluster changelog was kept separate up to version 4.1.13 or 5.0.7,
-respectively. Afterwards, and for all 5.1 versions, the Cluster
+respectively. Afterward, and for all 5.1 versions, the Cluster
 changelog was merged into the general server changelog.
 -->
 <section id="mysql-cluster-change-history">


Modified: trunk/refman-common/news-innodb.xml
===================================================================
--- trunk/refman-common/news-innodb.xml	2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-common/news-innodb.xml	2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 591 bytes

@@ -7,7 +7,7 @@
 ]>
 <!--
 The InnoDB changelog was kept separate up to version 4.0.21 or 4.1.4,
-respectively. Afterwards, and for all 5.0 versions, the InnoDB changelog was
+respectively. Afterward, and for all 5.0 versions, the InnoDB changelog was
 merged into the general server changelog.
 -->
 <section id="innodb-change-history">


Thread
svn commit - mysqldoc@docsrva: r21675 - in trunk: . dynamic-docs/changelog dynamic-docs/glossary innodb-plugin-1.1 mysqldoc-guide refman-4.1 refman-5....paul.dubois12 Jul