[svnbook] r5575 committed - branches/1.7/en

cmpilato at users.sourceforge.net cmpilato at users.sourceforge.net
Tue Jan 9 11:14:16 CST 2018

Revision: 5575
Author:   cmpilato
Date:     2018-01-09 17:14:15 +0000 (Tue, 09 Jan 2018)
Log Message:
Merge from ^/trunk/en r5572, r5573, and r5574 (hook script markup tweaks).

Modified Paths:

Property Changed:

Index: branches/1.7/en
--- branches/1.7/en	2018-01-09 17:07:43 UTC (rev 5574)
+++ branches/1.7/en	2018-01-09 17:14:15 UTC (rev 5575)

Property changes on: branches/1.7/en
Modified: svn:mergeinfo
## -1 +1 ##
\ No newline at end of property
\ No newline at end of property
Modified: branches/1.7/en/book/ch03-advanced-topics.xml
--- branches/1.7/en/book/ch03-advanced-topics.xml	2018-01-09 17:07:43 UTC (rev 5574)
+++ branches/1.7/en/book/ch03-advanced-topics.xml	2018-01-09 17:14:15 UTC (rev 5575)
@@ -3408,14 +3408,13 @@
         <para>Subversion defaults to the <quote>softer</quote>
           approach, but still allows administrators to create stricter
           enforcement policies through the use of hook scripts.  In
-          particular, the <filename>pre-lock</filename> and
-          <filename>pre-unlock</filename> hooks allow administrators
+          particular, the pre-lock and
+          pre-unlock hooks allow administrators
           to decide when lock creation and lock releases are allowed
           to happen.  Depending on whether a lock already exists,
           these two hooks can decide whether to allow a certain user
           to break or steal a lock.  The
-          <filename>post-lock</filename> and
-          <filename>post-unlock</filename> hooks are also available,
+          post-lock and post-unlock hooks are also available,
           and can be used to send email after locking actions.  To
           learn more about repository hooks, see <xref
           linkend="svn.reposadmin.create.hooks" />.</para>

Modified: branches/1.7/en/book/ch04-branching-and-merging.xml
--- branches/1.7/en/book/ch04-branching-and-merging.xml	2018-01-09 17:07:43 UTC (rev 5574)
+++ branches/1.7/en/book/ch04-branching-and-merging.xml	2018-01-09 17:14:15 UTC (rev 5575)
@@ -2841,7 +2841,7 @@
         repository to prevent older clients from committing changes.
         The easy way to do this is by inspecting
         the <quote>capabilities</quote> parameter in
-        the <literal>start-commit</literal> hook script.  If the
+        the start-commit hook script.  If the
         client reports itself as having <literal>mergeinfo</literal>
         capabilities, the hook script can allow the commit to start.
         If the client doesn't report that capability, have the hook

Modified: branches/1.7/en/book/ch05-repository-admin.xml
--- branches/1.7/en/book/ch05-repository-admin.xml	2018-01-09 17:07:43 UTC (rev 5574)
+++ branches/1.7/en/book/ch05-repository-admin.xml	2018-01-09 17:14:15 UTC (rev 5575)
@@ -1009,7 +1009,7 @@
           inconsistency can lead to surprising and unexpected
           behavior.  Instead of modifying the transaction, you should
           simply <emphasis>validate</emphasis> the transaction in the
-          <filename>pre-commit</filename> hook and reject the commit
+          pre-commit hook and reject the commit
           if it does not meet the desired requirements.  As a
           bonus, your users will learn the value of careful,
           compliance-minded work habits.</para>
@@ -1149,8 +1149,8 @@
           attempts to change the repository.  <command>svnlook</command>
           is typically used by the repository hooks for reporting the
           changes that are about to be committed (in the case of the
-          <command>pre-commit</command> hook) or that were just
-          committed (in the case of the <command>post-commit</command>
+          pre-commit hook) or that were just
+          committed (in the case of the post-commit
           hook) to the repository.  A repository administrator may use
           this tool for diagnostic purposes.</para>
@@ -1487,7 +1487,7 @@
       <para>Sometimes a user will have an error in her log message (a
         misspelling or some misinformation, perhaps).  If the
         repository is configured (using the
-        <literal>pre-revprop-change</literal> hook; see <xref
+        pre-revprop-change hook; see <xref
         linkend="svn.reposadmin.create.hooks"/>) to accept changes to
         this log message after the commit is finished, the user
         can <quote>fix</quote> her log message remotely using
@@ -1515,8 +1515,8 @@
       <para>The <command>svnadmin setlog</command> command, by
         default, is still bound by the same protections against
         modifying unversioned properties as a remote client
-        is—the <literal>pre-revprop-change</literal> and
-        <literal>post-revprop-change</literal> hooks are still
+        is—the pre-revprop-change and
+        post-revprop-change hooks are still
         triggered, and therefore must be set up to accept changes of
         this nature.  But an administrator can get around these
         protections by passing the <option>--bypass-hooks</option>
@@ -2254,7 +2254,7 @@
         <para>Another neat trick you can perform with this
           <option>--incremental</option> option involves appending to an
           existing dump file a new range of dumped revisions.  For
-          example, you might have a <literal>post-commit</literal> hook
+          example, you might have a post-commit hook
           that simply appends the repository dump of the single revision
           that triggered the hook.  Or you might have a script that runs
           nightly to append dump file data for all the revisions that
@@ -2824,7 +2824,7 @@
           that only it is doing those things.  We accomplish this by
           implementing two of the repository event
           hooks—pre-revprop-change and start-commit.  Our
-          <filename>pre-revprop-change</filename> hook script is found
+          pre-revprop-change hook script is found
           in <xref
           />, and basically verifies that the user attempting the
@@ -2848,7 +2848,7 @@
         <para>That covers revision property changes.  Now we need to
           ensure that only the <literal>syncuser</literal> user is
           permitted to commit new revisions to the repository.  We do
-          this using a <filename>start-commit</filename> hook script
+          this using a start-commit hook script
           such as the one in <xref

Modified: branches/1.7/en/book/ch06-server-configuration.xml
--- branches/1.7/en/book/ch06-server-configuration.xml	2018-01-09 17:07:43 UTC (rev 5574)
+++ branches/1.7/en/book/ch06-server-configuration.xml	2018-01-09 17:14:15 UTC (rev 5575)
@@ -1903,7 +1903,7 @@
       <para>Of course, you might have already set up
-        a <filename>pre-commit</filename> hook script to prevent
+        a pre-commit hook script to prevent
         commits (see <xref linkend="svn.reposadmin.create.hooks"/>).
         But as you read on, you'll see that it's also possible to use
         Apache's built-in methods to restrict access in specific
@@ -3119,7 +3119,7 @@
           <para>First, make sure that each slave repository has a
-            <filename>pre-revprop-change</filename> hook script which
+            pre-revprop-change hook script which
             allows remote revision property changes.  (This is
             standard procedure for being on the receiving end of
             <command>svnsync</command>.) Then log into the master
@@ -3174,7 +3174,7 @@
           <para>After this is done, we configure the master server's
-            <literal>post-commit</literal> hook script to invoke
+            post-commit hook script to invoke
             <command>svnsync</command> on each slave server:</para>
@@ -3196,8 +3196,8 @@
             commands to run in the background so that the Subversion
             client isn't left waiting forever for the commit to
             finish.  In addition to this
-            <literal>post-commit</literal> hook, you'll need a
-            <literal>post-revprop-change</literal> hook as well so
+            post-commit hook, you'll need a
+            post-revprop-change hook as well so
             that when a user, say, modifies a log message, the slave
             servers get that change also:</para>

More information about the svnbook-dev mailing list