--- a/README	Wed Apr 23 09:23:32 2008 +0100
+++ b/README	Thu Apr 24 08:27:30 2008 +0100
@@ -20,8 +20,6 @@
 developers who have access, and a file "hg-ssh-access.conf" which
 gives a set of rules defining who can do what to what.
 
-HOW IT WORKS
-
 All of the repositories controlled by these tools are owned by a
 single user (the "hg" user in what follows), but many remote users can
 act on them.  We don't use file permissions to achieve that - instead,
@@ -29,75 +27,23 @@
 host using ssh, using ssh URLs of the form
 "ssh://hg@repository-host/repository-name".  A restricted shell
 prevents them from using this access for unauthorized purposes.
-
 Developers are authenticated only using SSH keys; no other form of
-authentication is supported.  When a developer attempts to connect to
-a repository via ssh, the SSH daemon searches for a match for that
-user's key in ~hg/.ssh/authorized_keys.  If the developer is
-authorised to connect to the repository they will have an entry in
-this file.  The entry includes a "command" prefix which specifies that
-the restricted shell should be used; this shell is passed an argument
-identifying the developer.  The shell parses the command the developer
-is trying to execute, and consults a rules file to see if that
-developer is allowed to perform that action on that repository.  The
-bulk of the work of the restricted shell is done by the Python program
-"hg-ssh", but the shell script "hg-ssh-wrapper" sets up some
-configuration so that you can change it to suit your local
-installation.
+authentication is supported.
 
-The file ~hg/.ssh/authorized_keys is generated by "refresh-auth",
-which recurses through a directory of files containing SSH keys and
-generates an entry in authorized_keys for each one, using the name of
-the key file as the identifier for the developer.  These keys will
-live in the "keys" subdirectory of a repository called "hgadmin".  A
-hook in this repository re-runs "refresh-auth" on the most recent
-version after every push.
+QUICK START
 
-Finally, a hook in an extension is run for each changeset that is
-remotely committed, which uses the rules file to determine whether to
-allow the changeset.
-
-GETTING STARTED
-
-This is only one setup - it can be tweaked in many ways, and is as
-specific as it is only in the interests of brevity.
+You will need 
 
-You, and all users of this repository host, will need SSH public key
-authentication set up, preferably working with ssh-agent so you don't
-have to type in your passphrase all the time.  I assume you've done
-that in what follows, so if you've done something different you'll
-need to change it appropriately.
-
-Issue these commands to get the repository host started.  These are
-written out here rather than encapsulated in a script because many of
-them may need to be different for your local setup.  You will need
-root access on the repository host, because you need to create a new
-user.
+- "sudo" installed
+- "sudo" root privileges
+- an ssh-key set up with ssh-agent
 
-   ssh -A repository-host
-   ssh-add -L >> /tmp/my-ssh-public-key
-   sudo adduser --system --shell /bin/sh --group --disabled-password \
-     --gecos "Mercurial repositories" hg
-   sudo -u hg -H -s
-   cd
-   mkdir -p admin repos/hgadmin/keys/admin .ssh
-   cd admin
-   hg clone http://hg.opensource.lshift.net/hg-admin-tools
-   cp hg-admin-tools/hg-ssh-wrapper hg-admin-tools/remote-hgrc ~
-   cd ../repos/hgadmin
-   hg init .
-   echo "init user=admin/*" > hg-ssh-access.conf
-   cp /tmp/my-ssh-public-key keys/admin/myname
-   hg add
-   hg commit -m "initial commit"
-   cp ~/admin/hg-admin-tools/hgadmin-hgrc .hg/hgrc
-   ../../admin/hg-admin-tools/refresh-auth ./hg-ssh-wrapper
-   exit
-   exit
-
-You are now the sole user able to change and create repositories on
-this repository host.  To administer these controls (and test your
-access), check out hgadmin:
+Ensure there is no user called "hg" on the repository host, and run
+"./install" to create them. You are now the sole user able to change
+and create repositories on this repository host.  To give access to
+others, check out hgadmin - as yourself, and on whichever host is most
+convenient, but using the ssh-key with which you set up the
+repository:
 
    mkdir ~/hg
    cd ~/hg
@@ -190,6 +136,33 @@
   write user=docs/* file=docs/*
   read user=docs/*
 
+HOW IT WORKS
+
+When a developer attempts to connect to a repository via ssh, the SSH
+daemon searches for a match for that user's key in
+~hg/.ssh/authorized_keys.  If the developer is authorised to connect
+to the repository they will have an entry in this file.  The entry
+includes a "command" prefix which specifies that the restricted shell
+should be used; this shell is passed an argument identifying the
+developer.  The shell parses the command the developer is trying to
+execute, and consults a rules file to see if that developer is allowed
+to perform that action on that repository.  The bulk of the work of
+the restricted shell is done by the Python program "hg-ssh", but the
+shell script "hg-ssh-wrapper" sets up some configuration so that you
+can change it to suit your local installation.
+
+The file ~hg/.ssh/authorized_keys is generated by "refresh-auth",
+which recurses through a directory of files containing SSH keys and
+generates an entry in authorized_keys for each one, using the name of
+the key file as the identifier for the developer.  These keys will
+live in the "keys" subdirectory of a repository called "hgadmin".  A
+hook in this repository re-runs "refresh-auth" on the most recent
+version after every push.
+
+Finally, a hook in an extension is run for each changeset that is
+remotely committed, which uses the rules file to determine whether to
+allow the changeset.
+
 LOCKING YOURSELF OUT
 
 If you find yourself "locked out" - that is, that you no longer have