doc/manual.docbook
changeset 146 04e74d4b3822
parent 145 bc2b93fa662d
child 147 b29a7088b132
--- a/doc/manual.docbook	Thu Oct 15 10:31:49 2009 +0100
+++ b/doc/manual.docbook	Thu Oct 15 10:35:31 2009 +0100
@@ -149,13 +149,14 @@
 <title>Using access.conf</title>
 <para>
 mercurial-server offers much more fine-grained access control than this division into two classes of users.  Let's suppose you wish to give Pat access to the <literal>widget</literal> repository, but no other.  We first copy Pat's SSH public key into the <filename
-class='directory'>keys/widget/pat</filename> directory in <literal>hgadmin</literal>.  Now mercurial-server knows about Pat's key, but will give Pat no access to anything because the key is not under either <filename
+class='directory'>keys/pat</filename> directory in <literal>hgadmin</literal>.  This tells mercurial-server about Pat's key, but gives Pat no access to anything because the key is not under either <filename
 class='directory'>keys/root</filename> or <filename
 class='directory'>keys/users</filename>.  To grant this key access, we must give mercurial-server a new access rule, so we create a file in <literal>hgadmin</literal> called <filename>access.conf</filename>, with the following contents:</para>
-<programlisting>write repo=widget user=widget/**
+<programlisting># Give Pat access to the "widget" repository
+write repo=widget user=pat
 </programlisting>
 <para>
-Pat will have read and write access as soon as we add, commit, and push these files.
+Pat will have read and write access to the <literal>widget</literal> repository as soon as we add, commit, and push these files.
 </para>
 <para>
 Each line of <filename>access.conf</filename> has the following syntax: