Changes between Version 17 and Version 18 of UsingPidginMercurial

Timestamp:

Sep 24, 2012, 2:32:58 PM (11 years ago)

Author:

datallah

Comment:

pet peeve - apostrophes for plurals

UsingPidginMercurial

@@ -9 +9 @@
 }}}
 
-== !Read/Write Access for Developers/CPW's/SoC Students ==
+== !Read/Write Access for Developers/CPWs/SoC Students ==
 
 === Configure Mercurial ===
@@ -40 +40 @@
 Pidgin's Mercurial repositories are served by the [http://www.lshift.net/mercurial-server.html mercurial-server] package.  This relies entirely upon SSH key-based authentication, providing access control and a layer of accountability.
 
-If you wish, you can simplify Mercurial ssh: URL's by adding the following to `~/.ssh/config`:
+If you wish, you can simplify Mercurial ssh: URLs by adding the following to `~/.ssh/config`:
 {{{
 Host hg.pidgin.im
@@ -68 +68 @@
 
 === Access Control ===
-Access control on Pidgin's Mercurial server is such that all developers can write to our master repositories, but each developer and CPW has their own repositories that anyone can read but only they can write to.  The repositories are structured like so (developers/CPW's listed here are for the purpose of example):
+Access control on Pidgin's Mercurial server is such that all developers can write to our master repositories, but each developer and CPW has their own repositories that anyone can read but only they can write to.  The repositories are structured like so (developers/CPWs listed here are for the purpose of example):
 
 {{{
@@ -97 +97 @@
 
 Access control is as follows:
-  * Developers and CPW's have write access to `pidgin/*`
+  * Developers and CPWs have write access to `pidgin/*`
   * Developers can create and modify repositories in `dev/$NICKNAME/`
   * Crazy Patch Writers can create and modify repositories in `cpw/$NICKNAME/*`
@@ -109 +109 @@
 
   1. Check out the `hgadmin` repo: `hg clone ssh://hg@hg.pidgin.im/hgadmin pidgin-hgadmin`
-  1. `cd pidgin-hgadmin/keys`.  Inhere  is a series of directories.  The format is self-explaining.  Developers go in `devs/$NICKNAME`, CPW's in `cpws/$NICKNAME`, SoC students in `soc/$NICKNAME`.  This is to allow a single developer, CPW, or SoC student to have multiple SSH keys, perhaps for multiple machines.
+  1. `cd pidgin-hgadmin/keys`.  Inhere  is a series of directories.  The format is self-explaining.  Developers go in `devs/$NICKNAME`, CPWs in `cpws/$NICKNAME`, SoC students in `soc/$NICKNAME`.  This is to allow a single developer, CPW, or SoC student to have multiple SSH keys, perhaps for multiple machines.
   1. Create the appropriate directory.
   1. Within this directory create a file named for the SSH key being added, for example `user@somehost`.
@@ -120 +120 @@
 
 === A Special Note About "root" Access ===
-As indicated above, people who have "root" access to mercurial-server have the ability to configure the server via the `hgadmin` repo.  They also have the ability to bypass all ACL's, and thus can write to any repository, including developers', CPWs', and SoC students' repositories.
+As indicated above, people who have "root" access to mercurial-server have the ability to configure the server via the `hgadmin` repo.  They also have the ability to bypass all ACLs, and thus can write to any repository, including developers', CPWs', and SoC students' repositories.
 
 Additionally, there is a safety net built into the mercurial-server configuration.  In `/etc/mercurial-server` on rock.pidgin.im is a default ACL (`access.conf`) and a `keys` directory structure.  This default ACL is what grants "root" users their privileges, and the `keys` directory structure contains the relevant keys in the `keys/root` directory. These keys are located here in the server's filesystem instead of in the hgadmin repository as a safety net.  When building the files used by mercurial-server, the tools ''always'' read from `/etc/mercurial-server` ''before'' reading from `hgadmin`; this allows access to the hgadmin repo in the event that it is damaged either through accidental or intentional means.  This safety net means that at least two people will ''always'' have access to our repositories.