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-common | paul | 5 Jan |
