Changes between Version 11 and Version 12 of UsingPidginMercurial

Timestamp:

Jul 6, 2012, 9:35:05 PM (12 years ago)

Author:

datallah

Comment:

Further tweaks - remove the explicit ssh based cloning instructions because it's better for people to clone over http.

UsingPidginMercurial

@@ -27 +27 @@
 {{{
 [diff]
-git = 1
+git = True
 
 [defaults]
@@ -44 +44 @@
 
 === SSH-based Push/Pull ===
-You can get your initial checkouts from Mercurial by:
-  * With SSH config above: `hg clone ssh://hg.pidgin.im/path/to/repo`
-  * Without SSH config above: `hg clone ssh://hg@hg.pidgin.im/path/to/repo`
+You can get your initial checkouts from Mercurial using the [wiki:"UsingPidginMercurial#PublicRead-onlyAccess" Public Read-only Access] instructions.
 
-Once initial clones are done, pulls are a simple matter of running `hg pull` within your working copy.  You may optionally add `-u` to have your checkout automatically updated if possible.
-
-Alternatively, you can clone the repository via http and add a `default-push` line to the `[paths]` section of the repository's `.hg/hgrc` file (you'll need to use the `hg@` prefix if you haven't set it via the SSH config):
+The configuration of the server is such that pushes can only be performed via SSH, so you'll want to add a `default-push` line to the `[paths]` section of the repository's `.hg/hgrc` file (you'll need to use the `hg@` prefix if you haven't set it via the SSH config):
 {{{
+[paths]
 default-push = ssh://hg.pidgin.im/path/to/repo
 }}}
 
-Pushes are a simple matter of `hg push` within your working copy.  If you need to push a new repository, you must clone:
-  * With SSH config above: `hg clone . ssh://hg.pidgin.im/path/to/repo` in working copy
-  * Without SSH config above: `hg clone . ssh://hg@hg.pidgin.im/path/to/repo` in working copy
+Once initial clones are done, pulls are a simple matter of running `hg pull` within your working copy.  You may optionally use `hg pull -u` to have your checkout automatically updated if possible.
+
+Alternatively, you can clone the repository via ssh using the URI in the `default-push` settings above if http access is problematic for some reason
+
+Pushes to existing repositories are a simple matter of `hg push` within your working copy.
+Creating a new repository on the server must be done using `hg clone`:
+  * `hg clone . ssh://hg.pidgin.im/path/to/repo` in working copy
+   * (you'll need to use the `hg@` prefix if you haven't set it via the SSH config)
 
 == Administration ==
 
 === Access Control ===
-Access control on Pidgin's Mercurial server is strict.  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 repositories.  The repositories are structured like so (developers/CPW's listed here are for the purpose of example):
 
 {{{
 hg.pidgin.im          # Mercurial server
  + pidgin               # "Official" Pidgin and libpurple repositories
- |  + main                # replaced im.pidgin.pidgin in Monotone
- |  + 2_x_y               # replaced im.pidgin.pidgin.2.x.y in Monotone
+ |  + main                # replaced im.pidgin.pidgin, im.pidgin.pidgin.2.x.y in Monotone
  + dev                  # Developers' repositories
  |  + darkrain            # for all repositories darkrain wishes to create
@@ -96 +97 @@
   * Crazy Patch Writers can create and modify repositories in `cpw/$NICKNAME/*`
   * Summer of Code students can create and modify repositories in `soc/$YEAR/$NICKNAME/*`
-  * All of the above have read access to any repository on the server.
+  * Public Read-only access is available for any repository on the server.
   * Those people with "root" access can do anything to any repository.  This access is strictly controlled.
 
@@ -117 +118 @@
 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.
 
-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 two keys in the `keys/root` directory.  These two keys belong to rekkanoryo and lschiere.  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 rekkanoryo and lschiere to always be able to access 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.
+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.
 
 == Hooks / Extensions ==