List:Commits« Previous MessageNext Message »
From:paul Date:January 5 2006 3:45pm
Subject:svn commit - mysqldoc@docsrva: r687 - in trunk: . refman-common
View as plain text  
Author: paul
Date: 2006-01-05 16:45:32 +0100 (Thu, 05 Jan 2006)
New Revision: 687

Log:
 r5869@frost:  paul | 2006-01-05 09:45:16 -0600
 Remove doubled words. (Bug#16109)


Modified:
   trunk/
   trunk/refman-common/maxdb.en.xml
   trunk/refman-common/news-4.0.xml
   trunk/refman-common/news-4.1.xml
   trunk/refman-common/news-5.0.xml
   trunk/refman-common/news-5.1.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5866
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1933
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5869
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1933

Modified: trunk/refman-common/maxdb.en.xml
===================================================================
--- trunk/refman-common/maxdb.en.xml	2006-01-05 15:26:56 UTC (rev 686)
+++ trunk/refman-common/maxdb.en.xml	2006-01-05 15:45:32 UTC (rev 687)
@@ -407,7 +407,7 @@
       The MySQL Reference Manual does not contain any MaxDB
       documentation other than the introduction given in this section.
       MaxDB has its own documentation, which is called the MaxDB library
-      and is is available at
+      and is available at
       <ulink url="&base-url-docs;maxdb/index.html" />.
     </para>
 

Modified: trunk/refman-common/news-4.0.xml
===================================================================
--- trunk/refman-common/news-4.0.xml	2006-01-05 15:26:56 UTC (rev 686)
+++ trunk/refman-common/news-4.0.xml	2006-01-05 15:45:32 UTC (rev 687)
@@ -133,7 +133,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>
@@ -281,7 +281,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>
@@ -382,7 +382,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>

Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml	2006-01-05 15:26:56 UTC (rev 686)
+++ trunk/refman-common/news-4.1.xml	2006-01-05 15:45:32 UTC (rev 687)
@@ -1483,7 +1483,7 @@
         <para>
           If a <literal>DROP DATABASE</literal> fails on a master server
           due to the presence of a non-database file in the database
-          directory, the master have have the database tables deleted,
+          directory, the master have the database tables deleted,
           but not the slaves. To deal with failed database drops, we now
           write <literal>DROP TABLE</literal> statements to the binary
           log for the tables so that they are dropped on slaves. (Bug
@@ -1962,7 +1962,7 @@
       <listitem>
         <para>
           <literal>GROUP_CONCAT()</literal> sometimes returned a result
-          with a different collation that that of its arguments. (Bug
+          with a different collation than that of its arguments. (Bug
           #10201)
         </para>
       </listitem>
@@ -2644,7 +2644,7 @@
 
       <listitem>
         <para>
-          For <literal>MEMORY</literal> tables, it was possible for for
+          For <literal>MEMORY</literal> tables, it was possible for
           updates to be performed using outdated key statistics when the
           updates involved only very small changes in a very few rows.
           This resulted in the random failures of queries such as
@@ -8035,7 +8035,7 @@
           <literal>FLOAT(3,1)</literal> stores a maximum value of 99.9.
           Previously, the server allowed larger numbers to be stored.
           That is, it stored a value such as 100.0 as 100.0. Now the
-          server clips clips 100.0 to the maximum allowable value of
+          server clips 100.0 to the maximum allowable value of
           99.9. If you have tables that were created before MySQL 4.1.2
           and that contain floating-point data not strictly legal for
           the column type, you should alter the data types of those

Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml	2006-01-05 15:26:56 UTC (rev 686)
+++ trunk/refman-common/news-5.0.xml	2006-01-05 15:45:32 UTC (rev 687)
@@ -730,7 +730,7 @@
 
       <listitem>
         <para>
-          Revised table locking locking to allow proper assessment of
+          Revised table locking to allow proper assessment of
           view security. (Bug #11555)
         </para>
       </listitem>
@@ -2432,7 +2432,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>
@@ -3979,7 +3979,7 @@
         <para>
           If a <literal>DROP DATABASE</literal> fails on a master server
           due to the presence of a non-database file in the database
-          directory, the master have have the database tables deleted,
+          directory, the master have the database tables deleted,
           but not the slaves. To deal with failed database drops, we now
           write <literal>DROP TABLE</literal> statements to the binary
           log for the tables so that they are dropped on slaves. (Bug
@@ -4810,7 +4810,7 @@
       <listitem>
         <para>
           <literal>GROUP_CONCAT()</literal> sometimes returned a result
-          with a different collation that that of its arguments. (Bug
+          with a different collation than that of its arguments. (Bug
           #10201)
         </para>
       </listitem>
@@ -5690,7 +5690,7 @@
         <para>
           There was a compression algorithm issue with
           <literal>myisampack</literal> for very large datasets (where
-          the total size of of all records in a single column was on the
+          the total size of all records in a single column was on the
           order of 3 GB or more) on 64-bit platforms. (A fix for other
           platforms was made in MySQL 5.0.6.) (Bug #8321)
         </para>
@@ -5818,7 +5818,7 @@
 
       <listitem>
         <para>
-          For <literal>MEMORY</literal> tables, it was possible for for
+          For <literal>MEMORY</literal> tables, it was possible for
           updates to be performed using outdated key statistics when the
           updates involved only very small changes in a very few rows.
           This resulted in the random failures of queries such as
@@ -6600,7 +6600,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>
@@ -8811,7 +8811,7 @@
           <literal>DECIMAL(3,1)</literal> stores a maximum value of
           99.9. Previously, the server allowed larger numbers to be
           stored. That is, it stored a value such as 100.0 as 100.0. Now
-          the server clips clips 100.0 to the maximum allowable value of
+          the server clips 100.0 to the maximum allowable value of
           99.9. If you have tables that were created before MySQL 5.0.3
           and that contain floating-point data not strictly legal for
           the column type, you should alter the data types of those

Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml	2006-01-05 15:26:56 UTC (rev 686)
+++ trunk/refman-common/news-5.1.xml	2006-01-05 15:45:32 UTC (rev 687)
@@ -44,7 +44,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>
@@ -133,7 +133,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>
@@ -418,7 +418,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>
@@ -594,7 +594,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>
@@ -668,7 +668,7 @@
     <remark role="note">
       References to bug numbers should be written after the sentence
       describing the bugfix, like this: This sentence describes the fix.
-      (Bug #nnnn) It is not necessary to to state that the bug was
+      (Bug #nnnn) It is not necessary to state that the bug was
       fixed, since "Bugs fixed" already implies this. Use the past tense
       in describing the bug.
     </remark>

Thread
svn commit - mysqldoc@docsrva: r687 - in trunk: . refman-commonpaul5 Jan