Each patch should include a short description/justification at the top. I tried to patch against CVS, but adminscripts.sgml didn't come with the checkout. Someone on IRC said there might be a problem now with the CVS server.
Anyway, I'm sorry if the patches are a bit of sync. I'm prepared to patch against CVS/SVN/darcs in the future. Mark
--- old-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-02-01 10:59:24.000000000 -0500 +++ new-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-02-01 10:59:25.000000000 -0500 @@ -23,8 +23,9 @@ <para>This will produce a number of scripts with the prefix <command>slonik_</command>. They eliminate tedium by always referring to a central configuration file -for the details of your site configuration. Most also include some command -line help with the "-h" option, making them easier to learn and use. +for the details of your site configuration. A documented. sample of this file is provided +in <filename>altperl/slon_tools.conf-sample</filename>. Most also include some command +line help with the "--help" option, making them easier to learn and use. </para> <para>Most generate Slonik scripts that are printed to STDOUT.
Thu Feb 1 10:54:49 EST 2007 [EMAIL PROTECTED] * remove reference to "cluster.nodes", which I found confusing. diff -rN -u old-slony1-1.2.5/doc/adminguide/adminscripts.sgml new-slony1-1.2.5/doc/adminguide/adminscripts.sgml --- old-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-02-01 11:00:04.000000000 -0500 +++ new-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-02-01 11:00:04.000000000 -0500 @@ -35,8 +35,8 @@ couple of occasions, to pretty calamitous actions. The savvy administrator should review the script <emphasis>before</emphasis> piping it to <xref linkend="slonik">.</para> -<sect3><title>Node/Cluster Configuration - cluster.nodes</title> -<indexterm><primary>cluster.nodes - node/cluster configuration for Perl tools</primary></indexterm> +<sect3><title>Support for Multiple Clusters</title> +<indexterm><primary>Multiple Cluster support for the altperl tools</primary></indexterm> <para>The UNIX environment variable <envar>SLONYNODES</envar> is used to determine what Perl configuration file will be used to control the
Thu Feb 1 10:56:10 EST 2007 [EMAIL PROTECTED] * clarify SLONYNODES docs a bit. diff -rN -u old-slony1-1.2.5/doc/adminguide/adminscripts.sgml new-slony1-1.2.5/doc/adminguide/adminscripts.sgml --- old-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-02-01 11:00:33.000000000 -0500 +++ new-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-02-01 11:00:33.000000000 -0500 @@ -40,7 +40,9 @@ <para>The UNIX environment variable <envar>SLONYNODES</envar> is used to determine what Perl configuration file will be used to control the -shape of the nodes in a &slony1; cluster.</para> +shape of the nodes in a &slony1; cluster. If it not provided a default +<filename>slon_tools.conf</filename> location will be referenced. +</para> <para>What variables are set up. <itemizedlist>
Thu Feb 1 10:56:39 EST 2007 [EMAIL PROTECTED] * remove some variable documenation, which seems to have drifted from what is actually in slon_tools.conf. I think the documentation provided in the example slon_tools.conf-sample is good enough, and having those docs in just one place is simpler to maintain. diff -rN -u old-slony1-1.2.5/doc/adminguide/adminscripts.sgml new-slony1-1.2.5/doc/adminguide/adminscripts.sgml --- old-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-02-01 11:00:58.000000000 -0500 +++ new-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-02-01 11:00:58.000000000 -0500 @@ -90,6 +90,7 @@ ); </programlisting> </sect3> + <sect3><title>Set configuration - cluster.set1, cluster.set2</title> <indexterm><primary>cluster.set1 - replication set configuration for Perl tools</primary></indexterm> @@ -103,35 +104,6 @@ <filename>create_set</filename>, as that is the only script used to control what tables will be in a particular replication set.</para> -<para>What variables are set up.</para> -<itemizedlist> -<listitem><para>$TABLE_ID = 44;</para> -<para> Each table must be identified by a unique number; this variable controls where numbering starts</para> -</listitem> -<listitem><para>$SEQUENCE_ID = 17;</para> -<para> Each sequence must be identified by a unique number; this variable controls where numbering starts</para> -</listitem> -<listitem><para>@PKEYEDTABLES</para> - -<para> An array of names of tables to be replicated that have a -defined primary key so that &slony1; can automatically select its key</para> -</listitem> -<listitem><para>%KEYEDTABLES</para> -<para> A hash table of tables to be replicated, where the hash index -is the table name, and the hash value is the name of a unique not null -index suitable as a "candidate primary key."</para> -</listitem> -<listitem><para>@SERIALTABLES</para> - -<para> An array of names of tables to be replicated that have no -candidate for primary key. &slony1; will add a key field based on a -sequence that &slony1; generates</para> -</listitem> -<listitem><para>@SEQUENCES</para> - -<para> An array of names of sequences that are to be replicated</para> -</listitem> -</itemizedlist> </sect3> <sect3><title>slonik_build_env</title> <indexterm><primary>slonik_build_env</primary></indexterm>
_______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
