bk commit - mysqldoc@docsrva tree (paul:1.3251)

[paul]

Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.3251 05/08/12 15:36:08 paul@stripped +5 -0
  Clarify that protocol compatibility isn't
  the only compatibility factor.

  refman/replication.xml
    1.18 05/08/12 15:36:07 paul@stripped +17 -15
    Clarify that protocol compatibility isn't
    the only compatibility factor.

  refman-common/news-4.1.xml
    1.27 05/08/12 15:36:07 paul@stripped +6 -5
    Format.

  refman-5.1/replication.xml
    1.8 05/08/12 15:36:07 paul@stripped +12 -10
    Sync.

  refman-5.0/replication.xml
    1.8 05/08/12 15:36:07 paul@stripped +12 -10
    Sync.

  refman-4.1/replication.xml
    1.15 05/08/12 15:36:07 paul@stripped +13 -11
    Sync.

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	paul
# Host:	kite-hub.kitebird.com
# Root:	/src/extern/MySQL/bk/mysqldoc

--- 1.7/refman-5.1/replication.xml	2005-08-10 12:41:02 -05:00
+++ 1.8/refman-5.1/replication.xml	2005-08-12 15:36:07 -05:00
@@ -1493,10 +1493,12 @@
     </para>
 
     <para>
-      The preceding information pertains the replication compatibility
-      at the protocol level. There can also be SQL-level compatibility
-      constraints, as discussed in
-      <xref linkend="replication-features"/>.
+      The preceding information pertains to replication compatibility at
+      the protocol level. However, there can be other constraints, such
+      as SQL-level compatibility issues. For example, a 4.1 master
+      cannot replicate to a 4.0 slave if the replicated statements use
+      SQL features available in 4.1 but not 4.0. These and other issues
+      are discussed in <xref linkend="replication-features"/>.
     </para>
 
   </section>
@@ -1604,11 +1606,10 @@
       information about replication is given in
       <xref linkend="innodb-and-mysql-replication"/>.
     </para>
-    
+
     <para>
-      Replication issues
-      with regard to stored routines and triggers is described in
-      <xref linkend="stored-procedure-logging"/>.
+      Replication issues with regard to stored routines and triggers is
+      described in <xref linkend="stored-procedure-logging"/>.
     </para>
 
 <!-- Remove the previous paragraph and replace it with the following
@@ -1623,6 +1624,7 @@
       <xref linkend="replication-row-based"/>.
     </para>
 -->
+
     <itemizedlist>
 
       <listitem>
@@ -1645,8 +1647,8 @@
       <listitem>
         <para>
           <emphasis>The following restriction applies to statement-based
-          replication only, not to row-based replication.</emphasis>
-          The functions handling user-level locks:
+          replication only, not to row-based replication.</emphasis> The
+          functions handling user-level locks:
           <literal>GET_LOCK()</literal>,
           <literal>RELEASE_LOCK()</literal>,
           <literal>IS_FREE_LOCK()</literal>,

--- 1.26/refman-common/news-4.1.xml	2005-08-12 14:58:11 -05:00
+++ 1.27/refman-common/news-4.1.xml	2005-08-12 15:36:07 -05:00
@@ -607,12 +607,13 @@
           <literal>zlib</literal> data vulnerability that could result
           in a buffer overflow and code execution.
           (<ulink
url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096">CAN-2005-2096</ulink>)
-          (Bug #11844). Shortly after MySQL 4.1.13 was released, a second
-          potential zlib security flaw was discovered and fixed - the issue
-          is tracked by the Mitre CVE ID
+          (Bug #11844). Shortly after MySQL 4.1.13 was released, a
+          second potential zlib security flaw was discovered and fixed -
+          the issue is tracked by the Mitre CVE ID
           (<ulink
url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1849">CAN-2005-1849</ulink>).
-          A patch for this flaw was applied on top of the 4.1.13 sources and
-          published as 4.1.13a. The affected binaries have been rebuilt.
+          A patch for this flaw was applied on top of the 4.1.13 sources
+          and published as 4.1.13a. The affected binaries have been
+          rebuilt.
         </para>
       </listitem>
 

--- 1.14/refman-4.1/replication.xml	2005-08-10 12:41:01 -05:00
+++ 1.15/refman-4.1/replication.xml	2005-08-12 15:36:07 -05:00
@@ -1483,6 +1483,15 @@
     </para>
 
     <para>
+      The preceding information pertains to replication compatibility at
+      the protocol level. However, there can be other constraints, such
+      as SQL-level compatibility issues. For example, a 4.1 master
+      cannot replicate to a 4.0 slave if the replicated statements use
+      SQL features available in 4.1 but not 4.0. These and other issues
+      are discussed in <xref linkend="replication-features"/>.
+    </para>
+
+    <para>
       The following table indicates master/slave replication
       compatibility between different versions of MySQL.
     </para>
@@ -1546,13 +1555,6 @@
       will also fail.
     </para>
 
-    <para>
-      The preceding information pertains the replication compatibility
-      at the protocol level. There can also be SQL-level compatibility
-      constraints, as discussed in
-      <xref linkend="replication-features"/>.
-    </para>
-
   </section>
 
   <section id="replication-upgrade">
@@ -1732,8 +1734,8 @@
       <listitem>
         <para>
           <emphasis>The following restriction applies to statement-based
-          replication only, not to row-based replication.</emphasis>
-          The functions handling user-level locks:
+          replication only, not to row-based replication.</emphasis> The
+          functions handling user-level locks:
           <literal>GET_LOCK()</literal>,
           <literal>RELEASE_LOCK()</literal>,
           <literal>IS_FREE_LOCK()</literal>,
@@ -1920,8 +1922,8 @@
       <listitem>
         <para>
           <emphasis>The following restriction applies to statement-based
-          replication only, not to row-based replication.</emphasis>
-          It is possible for the data on the master and slave to become
+          replication only, not to row-based replication.</emphasis> It
+          is possible for the data on the master and slave to become
           different if a query is designed in such a way that the data
           modification is non-deterministic; that is, left to the will
           of the query optimizer. (That generally is not a good practice

--- 1.17/refman/replication.xml	2005-08-10 12:41:03 -05:00
+++ 1.18/refman/replication.xml	2005-08-12 15:36:07 -05:00
@@ -1570,6 +1570,15 @@
     </para>
 
     <para>
+      The preceding information pertains to replication compatibility at
+      the protocol level. However, there can be other constraints, such
+      as SQL-level compatibility issues. For example, a 4.1 master
+      cannot replicate to a 4.0 slave if the replicated statements use
+      SQL features available in 4.1 but not 4.0. These and other issues
+      are discussed in <xref linkend="replication-features"/>.
+    </para>
+
+    <para>
       The following table indicates master/slave replication
       compatibility between different versions of MySQL.
     </para>
@@ -1633,13 +1642,6 @@
       will also fail.
     </para>
 
-    <para>
-      The preceding information pertains the replication compatibility
-      at the protocol level. There can also be SQL-level compatibility
-      constraints, as discussed in
-      <xref linkend="replication-features"/>.
-    </para>
-
   </section>
 
   <section id="replication-upgrade">
@@ -1836,11 +1838,10 @@
       information about replication is given in
       <xref linkend="innodb-and-mysql-replication"/>.
     </para>
-    
+
     <para>
-      Replication issues
-      with regard to stored routines and triggers is described in
-      <xref linkend="stored-procedure-logging"/>.
+      Replication issues with regard to stored routines and triggers is
+      described in <xref linkend="stored-procedure-logging"/>.
     </para>
 
 <!-- Remove the previous paragraph and replace it with the following
@@ -1855,6 +1856,7 @@
       <xref linkend="replication-row-based"/>.
     </para>
 -->
+
     <itemizedlist>
 
       <listitem>
@@ -1890,8 +1892,8 @@
       <listitem>
         <para>
           <emphasis>The following restriction applies to statement-based
-          replication only, not to row-based replication.</emphasis>
-          The functions handling user-level locks:
+          replication only, not to row-based replication.</emphasis> The
+          functions handling user-level locks:
           <literal>GET_LOCK()</literal>,
           <literal>RELEASE_LOCK()</literal>,
           <literal>IS_FREE_LOCK()</literal>,
@@ -2078,8 +2080,8 @@
       <listitem>
         <para>
           <emphasis>The following restriction applies to statement-based
-          replication only, not to row-based replication.</emphasis>
-          It is possible for the data on the master and slave to become
+          replication only, not to row-based replication.</emphasis> It
+          is possible for the data on the master and slave to become
           different if a query is designed in such a way that the data
           modification is non-deterministic; that is, left to the will
           of the query optimizer. (That generally is not a good practice

--- 1.7/refman-5.0/replication.xml	2005-08-10 12:41:01 -05:00
+++ 1.8/refman-5.0/replication.xml	2005-08-12 15:36:07 -05:00
@@ -1493,10 +1493,12 @@
     </para>
 
     <para>
-      The preceding information pertains the replication compatibility
-      at the protocol level. There can also be SQL-level compatibility
-      constraints, as discussed in
-      <xref linkend="replication-features"/>.
+      The preceding information pertains to replication compatibility at
+      the protocol level. However, there can be other constraints, such
+      as SQL-level compatibility issues. For example, a 4.1 master
+      cannot replicate to a 4.0 slave if the replicated statements use
+      SQL features available in 4.1 but not 4.0. These and other issues
+      are discussed in <xref linkend="replication-features"/>.
     </para>
 
   </section>
@@ -1604,11 +1606,10 @@
       information about replication is given in
       <xref linkend="innodb-and-mysql-replication"/>.
     </para>
-    
+
     <para>
-      Replication issues
-      with regard to stored routines and triggers is described in
-      <xref linkend="stored-procedure-logging"/>.
+      Replication issues with regard to stored routines and triggers is
+      described in <xref linkend="stored-procedure-logging"/>.
     </para>
 
 <!-- Remove the previous paragraph and replace it with the following
@@ -1623,6 +1624,7 @@
       <xref linkend="replication-row-based"/>.
     </para>
 -->
+
     <itemizedlist>
 
       <listitem>
@@ -1645,8 +1647,8 @@
       <listitem>
         <para>
           <emphasis>The following restriction applies to statement-based
-          replication only, not to row-based replication.</emphasis>
-          The functions handling user-level locks:
+          replication only, not to row-based replication.</emphasis> The
+          functions handling user-level locks:
           <literal>GET_LOCK()</literal>,
           <literal>RELEASE_LOCK()</literal>,
           <literal>IS_FREE_LOCK()</literal>,