225 but not create repositories. If these are the only rules in effect, they

   225 but not create repositories.  Some examples of how these rules work:

   226 have the following consequences:

   226 </para>

   227 </para>

   227 <itemizedlist>

   228 <itemizedlist>

   228 <listitem>

   229 <listitem>

   229 User <filename class='directory'>root/jay</filename> creates a repository

   230 Any request from a user with a key under <filename

   230 <filename class='directory'>foo/bar/baz</filename>. This matches the first

   231 class='directory'>keys/root</filename> will match the first rule; since

   231 rule and so will be allowed.

   232 this rule is <literal>init</literal> the request will always be allowed.

   232 </listitem>

   233 </listitem>

   233 <listitem>

   234 <listitem>

   234 User <filename class='directory'>root/jay</filename> changes repository

   235 Any request to access the <literal>hgadmin</literal> by any other user will

   235 <filename class='directory'>hgadmin</filename>. Again, this matches the

   236 not match the first rule, but will match the second rule, and so will be

   236 first rule and so will be allowed; later rules have no effect.

   237 denied.

   237 </listitem>

   238 </listitem>

   238 <listitem>

   239 <listitem>

   239 User <filename class='directory'>users/sam</filename> tries to read

   240 Any request to create a repository from a user with a key in <filename

   240 repository <filename class='directory'>hgadmin</filename>. This does not

   241 class='directory'>keys/users</filename> will not match the first or second

   241 match the first rule, but matches the second, and so will be denied.

   242 rules, but will match the third rule. This is a <literal>write</literal>

   242 </listitem>

   243 rule, which doesn't grant the privilege to create repositories, so the

   243 <listitem>

   244 request will be denied.

   244 User <filename class='directory'>users/sam</filename> tries to create

   245 </listitem>

   245 repository <filename class='directory'>sams-project</filename>. This does

   246 <listitem>

   246 not match the first two rules, but matches the third; this is a

   247 Any request to access an existing repository from a user with a key in

   247 <literal>write</literal> rule, which doesn't grant the privilege to create

   248 <filename class='directory'>keys/users</filename> will not match the first

   248 repositories, so the request will be denied.

   249 or second rules, but will match the third rule, which grants

   249 </listitem>

   250 <literal>write</literal> privilege, so the request will be allowed.

   250 <listitem>

   251 </listitem>

   251 User <filename class='directory'>users/sam</filename> writes to existing

   252 <listitem>

   252 repository <filename class='directory'>projects/main</filename>. Again,

   253 Any request from any user whose key is in neither <filename

   253 this matches the third rule, which allows the request.

   254 class='directory'>keys/root</filename> nor <filename

   254 </listitem>

   255 class='directory'>keys/users</filename> will not match any rule and so will

   255 <listitem>

   256 be denied. Unless it matches the second rule, in which case it will still

   256 User <filename class='directory'>pat</filename> tries to write to existing

   257 be denied.  Changes to the <filename>access.conf</filename> in <literal>hgadmin</literal> will change that, as the example at the start of this section shows.

   257 repository <filename class='directory'>widget</filename>. Until we change

   258 the <filename>access.conf</filename> file in <filename

   259 class='directory'>hgadmin</filename>, this will match no rule, and so will

   260 be denied.