[svnbook] r5442 committed - trunk/en/book/ch05-repository-admin.xml
cmpilato at users.sourceforge.net
cmpilato at users.sourceforge.net
Mon Oct 2 09:39:14 CDT 2017
Revision: 5442
http://sourceforge.net/p/svnbook/source/5442
Author: cmpilato
Date: 2017-10-02 14:39:14 +0000 (Mon, 02 Oct 2017)
Log Message:
-----------
* en/book/ch05-repository-admin.xml
Rework the warning to hook script authors to note that it's okay to
add new transaction properties, but assume everything else is
off-limits.
Modified Paths:
--------------
trunk/en/book/ch05-repository-admin.xml
Modified: trunk/en/book/ch05-repository-admin.xml
===================================================================
--- trunk/en/book/ch05-repository-admin.xml 2017-10-02 14:00:32 UTC (rev 5441)
+++ trunk/en/book/ch05-repository-admin.xml 2017-10-02 14:39:14 UTC (rev 5442)
@@ -962,23 +962,24 @@
APIs.</para>
<warning>
- <para>While hook scripts can do almost anything, there is
- one dimension in which hook script authors should show
- restraint: do <emphasis>not</emphasis> modify a commit
- transaction using hook scripts. While it might be
- tempting to use hook scripts to automatically correct
- errors, shortcomings, or policy violations present in the
- files being committed, doing so can cause problems.
- Subversion keeps client-side caches of certain bits of
- repository data, and if you change a commit transaction in
- this way, those caches become indetectably stale. This
- 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 if it does not meet the desired
- requirements. As a bonus, your users will learn the value
- of careful, compliance-minded work habits.</para>
+ <para>Hook scripts can do almost anything, but hook script
+ authors should show restraint. It might be tempting to,
+ say, use hook scripts to automatically correct errors,
+ shortcomings, or policy violations present in the files
+ being committed. Unfortunately, doing so can cause
+ problems. Subversion keeps client-side caches of certain
+ bits of repository data, and if you change a commit
+ transaction in this way, those caches become indetectably
+ stale, leading to surprising and unexpected behavior.
+ While it is generally okay to add new commit transaction
+ properties via a hook script, essentially everything else
+ about a commit transaction should be considered read-only.
+ Instead of modifying a transaction to polish its payload,
+ simply <emphasis>validate</emphasis> the transaction in
+ the <filename>pre-commit</filename> 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>
</warning>
</sect3>
More information about the svnbook-dev
mailing list