Author: paul
Date: 2006-01-26 21:24:28 +0100 (Thu, 26 Jan 2006)
New Revision: 1050
Log:
r2562@kite-hub: paul | 2006-01-26 14:24:18 -0600
Cleanup revisions.
Modified:
trunk/
trunk/refman-4.1/database-administration.xml
trunk/refman-4.1/innodb.xml
trunk/refman-4.1/replication.xml
trunk/refman-4.1/storage-engines.xml
trunk/refman-5.0/database-administration.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.0/replication.xml
trunk/refman-5.0/storage-engines.xml
trunk/refman-5.1/database-administration.xml
trunk/refman-5.1/innodb.xml
trunk/refman-5.1/replication.xml
trunk/refman-5.1/storage-engines.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6690
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2560
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6690
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2562
Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-4.1/database-administration.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -2840,7 +2840,7 @@
<para>
If this is set to a non-zero value, all tables are closed
every <literal>flush_time</literal> seconds to free up
- resources and sync unflushed data to disk. We recommend
+ resources and synchronize unflushed data to disk. We recommend
this option only on Windows 9x or Me, or on systems with
minimal resources available. This variable was added in
MySQL 3.22.18.
@@ -20305,7 +20305,7 @@
rolled back <literal>InnoDB</literal> transactions from the
binary log. This ensures that the binary log reflects the exact
state of <literal>InnoDB</literal> tables, and thus, that the
- slave remains in sync with the master (and does not receive any
+ slave remains in synchrony with the master (and does not receive any
statements which have been rolled back).
</para>
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-4.1/innodb.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -7242,7 +7242,7 @@
DATABASE</literal> in MySQL versions before 3.23.44, or the
server crashes in the middle of a data dictionary operation, the
locations of the <filename>.frm</filename> files may end up out
- of sync with the locations recorded in the
+ of synchrony with the locations recorded in the
<literal>InnoDB</literal> internal data dictionary.
</para>
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-4.1/replication.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -3110,7 +3110,7 @@
and client programs, and no bugs in MySQL itself, an error
that stops replication should never occur. Indiscriminate use
of this option results in slaves becoming hopelessly out of
- sync with the master, with you having no idea why this has
+ synchrony with the master, with you having no idea why this has
occurred.
</para>
@@ -3595,7 +3595,7 @@
master/slave relationship over a dial-up link where the link is up
only sporadically and for short periods of time. The implication
of this is that, at any given time, the slave is not guaranteed to
- be in sync with the master unless you take some special measures.
+ be in synchrony with the master unless you take some special measures.
In the future, we will have the option to block the master until
at least one slave is in sync.
</para>
@@ -3681,7 +3681,7 @@
<para>
The <literal>SELECT</literal> statement blocks until the slave
reaches the specified log file and offset. At that point, the
- slave is in sync with the master and the statement returns.
+ slave is in synchrony with the master and the statement returns.
</para>
</listitem>
Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-4.1/storage-engines.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -1533,7 +1533,7 @@
</itemizedlist>
<para>
- In other words, the counter can go out of sync only under
+ In other words, the counter can become incorrect only under
these conditions:
</para>
Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-5.0/database-administration.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -3130,7 +3130,7 @@
<para>
If this is set to a non-zero value, all tables are closed
every <literal>flush_time</literal> seconds to free up
- resources and sync unflushed data to disk. We recommend
+ resources and synchronize unflushed data to disk. We recommend
that this option be used only on Windows 9x or Me, or on
systems with minimal resources.
</para>
@@ -22378,7 +22378,7 @@
<literal>InnoDB</literal> transactions from the binary log. This
ensures that the binary log reflects the exact data of
<literal>InnoDB</literal> tables, and so, that the slave remains
- in sync with the master (not receiving a statement which has
+ in synchrony with the master (not receiving a statement which has
been rolled back).
</para>
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-5.0/innodb.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -7178,7 +7178,7 @@
own data dictionary inside the tablespace files. If you move
<filename>.frm</filename> files around, or if the server crashes
in the middle of a data dictionary operation, the locations of
- the <filename>.frm</filename> files may end up out of sync with
+ the <filename>.frm</filename> files may end up out of synchrony with
the locations recorded in the <literal>InnoDB</literal> internal
data dictionary.
</para>
Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-5.0/replication.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -2977,7 +2977,7 @@
and client programs, and no bugs in MySQL itself, an error
that stops replication should never occur. Indiscriminate use
of this option results in slaves becoming hopelessly out of
- sync with the master, with you having no idea why this has
+ synchrony with the master, with you having no idea why this has
occurred.
</para>
@@ -3492,7 +3492,7 @@
master/slave relationship over a dial-up link where the link is up
only sporadically and for short periods of time. The implication
of this is that, at any given time, the slave is not guaranteed to
- be in sync with the master unless you take some special measures.
+ be in synchrony with the master unless you take some special measures.
In the future, we will have the option to block the master until
at least one slave is in sync.
</para>
@@ -3574,7 +3574,7 @@
<para>
The <literal>SELECT</literal> statement blocks until the slave
reaches the specified log file and offset. At that point, the
- slave is in sync with the master and the statement returns.
+ slave is in synchrony with the master and the statement returns.
</para>
</listitem>
Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-5.0/storage-engines.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -1537,7 +1537,7 @@
</itemizedlist>
<para>
- In other words, the counter can go out of sync only under
+ In other words, the counter can become incorrect only under
these conditions:
</para>
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-5.1/database-administration.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -3157,7 +3157,7 @@
<para>
If this is set to a non-zero value, all tables are closed
every <literal>flush_time</literal> seconds to free up
- resources and sync unflushed data to disk. We recommend
+ resources and synchronize unflushed data to disk. We recommend
that this option be used only on Windows 9x or Me, or on
systems with minimal resources.
</para>
@@ -22387,7 +22387,7 @@
<literal>InnoDB</literal> transactions from the binary log. This
ensures that the binary log reflects the exact data of
<literal>InnoDB</literal> tables, and so, that the slave remains
- in sync with the master (not receiving a statement which has
+ in synchrony with the master (not receiving a statement which has
been rolled back).
</para>
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-5.1/innodb.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -7102,7 +7102,7 @@
own data dictionary inside the tablespace files. If you move
<filename>.frm</filename> files around, or if the server crashes
in the middle of a data dictionary operation, the locations of
- the <filename>.frm</filename> files may end up out of sync with
+ the <filename>.frm</filename> files may end up out of synchrony with
the locations recorded in the <literal>InnoDB</literal> internal
data dictionary.
</para>
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-5.1/replication.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -3141,7 +3141,7 @@
and client programs, and no bugs in MySQL itself, an error
that stops replication should never occur. Indiscriminate use
of this option results in slaves becoming hopelessly out of
- sync with the master, with you having no idea why this has
+ synchrony with the master, with you having no idea why this has
occurred.
</para>
@@ -3648,7 +3648,7 @@
master/slave relationship over a dial-up link where the link is up
only sporadically and for short periods of time. The implication
of this is that, at any given time, the slave is not guaranteed to
- be in sync with the master unless you take some special measures.
+ be in synchrony with the master unless you take some special measures.
In the future, we will have the option to block the master until
at least one slave is in sync.
</para>
@@ -3730,7 +3730,7 @@
<para>
The <literal>SELECT</literal> statement blocks until the slave
reaches the specified log file and offset. At that point, the
- slave is in sync with the master and the statement returns.
+ slave is in synchrony with the master and the statement returns.
</para>
</listitem>
Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml 2006-01-26 20:14:54 UTC (rev 1049)
+++ trunk/refman-5.1/storage-engines.xml 2006-01-26 20:24:28 UTC (rev 1050)
@@ -1510,7 +1510,7 @@
</itemizedlist>
<para>
- In other words, the counter can go out of sync only under
+ In other words, the counter can become incorrect only under
these conditions:
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1050 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 26 Jan |
