# HG changeset patch
# User Paul Crowley <paul@lshift.net>
# Date 1255599331 -3600
# Node ID 04e74d4b3822687df038c7c96966957bfcef4b3c
# Parent  bc2b93fa662d40479df83767a589ea46edf84ac8
Simplify Pat story

diff -r bc2b93fa662d -r 04e74d4b3822 doc/manual.docbook
--- 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: