Merge
authorPaul Crowley <paul@lshift.net>
Thu, 15 Oct 2009 10:24:50 +0100
changeset 143 afb1d57ca9f7
parent 140 0f79d1bea07e (diff)
parent 142 fb64f9ac44c5 (current diff)
child 144 2dbaddde1fd5
Merge
doc/manual.docbook
--- a/doc/manual.docbook	Thu Oct 15 09:26:19 2009 +0100
+++ b/doc/manual.docbook	Thu Oct 15 10:24:50 2009 +0100
@@ -267,7 +267,8 @@
 <caution>
 The way these conditions work is subtle and can be counterintuitive. Unless
 you need what they provide, ignore this section, stick to user and repo
-conditions, and then things are likely to work the way you would expect.
+conditions, and then things are likely to work the way you would expect. If
+you do need what they provide, read what follows very carefully.
 </caution>
 <para>
 File and branch conditions are added to the conditions against which a rule
@@ -296,18 +297,20 @@
 Whether to allow any access to a repository
 </listitem>
 <listitem>
-Whether to allow a changeset, which is on a some branch
-</listitem>
-<listitem>
-Whether to allow a changeset which changes a particular file
+Whether to allow a changeset
 </listitem>
 </itemizedlist>
 <para>
 When the first two of these decisions are being made, nothing is known
-about what files might be changed, and so all file and branch conditions
-automatically succeed for the purpose of such decisions. This means that
-doing tricky things with file conditions can have counterintuitive
-consequences:
+about any changsets that might be pushed, and so all file and branch
+conditions automatically succeed for the purpose of such decisions. For the
+third condition, every file changed in the changeset must be allowed by a
+<literal>write</literal> or <literal>init</literal> rule for the changeset
+to be allowed.
+</para>
+<para>
+This means that doing tricky things with file conditions can have
+counterintuitive consequences:
 </para>
 <itemizedlist>
 <listitem>