Log Message:
-----------
Make it clearer that SUBSCRIBE SET has two functionalities:
 1.  Setting up new subscriptions (which copy data from scratch)
 2.  Revising subscriptions (which doesn't copy data from scratch)

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        reshape.sgml (r1.19 -> r1.20)
        slonik_ref.sgml (r1.59 -> r1.60)

-------------- next part --------------
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.59
retrieving revision 1.60
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.59 -r1.60
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -1892,6 +1892,11 @@
    <refsect1>
     <title>Description</title>
     
+    <para> This performs one of two actions: </para>
+
+    <itemizedlist>
+ 
+    <listitem><para> Initiates replication for a replication set </para>
     <para> Causes a node (subscriber) to start replicating a set of
     tables either from the origin or from another provider node, which
     must itself already be be an active, forwarding subscriber.</para>
@@ -1950,14 +1955,21 @@
      until the provider is ready.</para>
 </warning>
 
-     <note><para> If you need to revise subscription information for a
+     </listitem>
+
+     <listitem><para> Revising subscription information for already-subscribed nodes. </para>
+
+     <para> If you need to revise subscription information for a
        node, you <emphasis>also</emphasis> submit the new information
        using this command, and the new configuration will be propagated
        throughout the replication network.  The normal reason to revise
        this information is that you want a node to subscribe to a
        <emphasis> different </emphasis> provider node, or for a node to
        become a <quote>forwarding</quote> subscriber so it may later
-       become the provider for a later subscriber.</para> </note>
+       become the provider for a later subscriber.</para>
+
+     </listitem>
+     </itemizedlist>
 
      <variablelist>
       <varlistentry><term><literal> ID = ival </literal></term>
@@ -1984,7 +1996,6 @@
 
       </varlistentry>
      </variablelist>
-    </para>
     <para> This uses &funsubscribeset;. </para>
    </refsect1>
    <refsect1><title>Example</title>
Index: reshape.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/reshape.sgml,v
retrieving revision 1.19
retrieving revision 1.20
diff -Ldoc/adminguide/reshape.sgml -Ldoc/adminguide/reshape.sgml -u -w -r1.19 -r1.20
--- doc/adminguide/reshape.sgml
+++ doc/adminguide/reshape.sgml
@@ -19,8 +19,11 @@
 its data from a different provider, or to change it to turn forwarding
 on or off.  This can be accomplished by issuing the slonik <xref
 linkend="stmtsubscribeset"> operation with the new subscription
-information for the node; &slony1; will change the
-configuration.</para></listitem>
+information for the node; &slony1; will change the configuration.  No
+need to ask for <xref linkend="stmtunsubscribeset">; no need for it to
+start copying data from scratch; the <xref linkend="stmtsubscribeset">
+request will reshape the subscription <quote>on the fly</quote> and
+allow data to remain consistent between nodes.  </para></listitem>
 
 <listitem><para> If the directions of data flows have changed, it is
 doubtless appropriate to issue a set of <xref