Changes between Version 23 and Version 24 of UsingPidginMercurial

03/28/16 12:28:57 (12 months ago)

We have moved to Bitbucket.


  • UsingPidginMercurial

    v23 v24  
    22The master copy of the source code for libpurple, Pidgin, Finch,, and resides in [ Mercurial] repositories.
    4 == Public Read-only Access ==
    5 All public Pidgin Mercurial repositories are available via HTTP/HTTPS from [].
     4All public Pidgin Mercurial repositories are available via HTTP/HTTPS from [ bitbucket].
    8 hg clone pidgin-main
     7hg clone
    11 There is also a [ clone at] that can be used for forking and pull requests.
    13 == !Read/Write Access for Developers/CPWs/SoC Students ==
    1510=== Configure Mercurial ===
    41 === Configure SSH for Access ===
    42 Pidgin's Mercurial repositories are served by the [ mercurial-server] package.  This relies entirely upon SSH key-based authentication, providing access control and a layer of accountability.
     36=== How the email and CIA notification works ===
    44 If you wish, you can simplify Mercurial ssh: URLs by adding the following to `~/.ssh/config`:
    45 {{{
    46 Host
    47     Protocol 2
    48     User hg
    49 }}}
     38[This may be a bit out-of-date after the move to Bitbucket.]
    51 === SSH-based !Push/Pull ===
    52 You can get your initial checkouts from Mercurial using the [wiki:"UsingPidginMercurial#PublicRead-onlyAccess" Public Read-only Access] instructions.
    54 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):
    55 {{{
    56 [paths]
    57 default-push = ssh://
    58 }}}
    60 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.
    62 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
    64 Pushes to existing repositories are a simple matter of `hg push` within your working copy.
    65 Creating a new repository on the server must be done using `hg clone`:
    66   * `hg clone . ssh://` in working copy
    67    * (you'll need to use the `hg@` prefix if you haven't set it via the SSH config)
    69 == Administration ==
    71 === Access Control ===
    72 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):
    74 {{{
    75          # Mercurial server
    76  + pidgin               # "Official" Pidgin and libpurple repositories
    77  |  + main                # replaced im.pidgin.pidgin, im.pidgin.pidgin.2.x.y in Monotone
    78  + private            # Non-public only accessible by developers (for embargoed security fixes)
    79  | + main               # Clone of pidgin/main with embargoed security fixes
    80  + dev                # Developers' repositories
    81  |  + darkrain          # for all repositories darkrain wishes to create
    82  |  |  + irc              # replaced im.pidgin.cpw.darkrain42.irc in Monotone
    83  |  |  + xmpp_roster      # replaced im.pidgin.cpw.darkrain42.xppp.roster in Monotone
    84  |  + rekkanoryo        # for all repositories rekkanoryo wishes to create
    85  |     + examples         # replaced im.pidgin.cpw.rekkanoryo.examples in Monotone
    86  + cpw                # Crazy Patch Writers' repositories
    87  |  + eionrobb          # for all repositories eionrobb wishes to create
    88  |     + newfeature        # new repository
    89  + www                # For websites
    90  |  + pidgin            # for
    91  |  + imfreedom         # for
    92  + util               # Supporting independent codebases
    93  | + hg_hooks           # various hg hooks
    94  | + hg_templates       # customized hgweb templates
    95  | + drmingw            # crash reporter used on windows builds
    96  | + mozilla-pushlog    # fork of mozilla hook used to keep track of pushes
    97  + soc                # For Google Summer of Code projects (lines below should be obvious)
    98     + 2007
    99     |  + student1
    100     |     + project1
    101     + ...
    102     + 2012
    103        + studentx
    104           + projectx
    105 }}}
    107 Access control is as follows:
    108   * Developers and CPWs have write access to `pidgin/*`
    109   * Developers have read / write access to `private/*` only via ssh
    110   * Developers can create and modify repositories in `dev/$NICKNAME/`
    111   * Crazy Patch Writers can create and modify repositories in `cpw/$NICKNAME/*`
    112   * Summer of Code students can create and modify repositories in `soc/$YEAR/$NICKNAME/*`
    113   * Public anonymous Read-only access is available for any repository on the server with the exception of those in the private tree.
    114   * Those people with "root" access can do anything to any repository.  This access is strictly controlled.
    117 === Adding New Users ===
    118 The process to allow new users SSH access to the Mercurial repositories is pretty simple, but requires someone with "root" access to mercurial-server.  Currently those people are datallah, markdoliner, rekkanoryo, elb, and lschiere.
    120   1. Check out the `hgadmin` repo: `hg clone ssh:// pidgin-hgadmin`
    121   1. `cd pidgin-hgadmin/keys`.  In here  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.
    122   1. Create the appropriate directory.
    123   1. Within this directory create a file named for the SSH key being added, for example `user@somehost`.
    124   1. Put the SSH public key in this file.
    125   1. `hg add $FILE`
    126   1. Go back to the root of `pidgin-hgadmin`.
    127   1. Edit `access.conf`.  Copy an existing line for the same class of user (developer, CPW, SoC student) and modify it as appropriate for the new person's nickname and, if applicable, SoC year.
    128   1. `hg commit`
    129   1. `hg push` (mercurial-server updates automatically on push)
    131 === A Special Note About "root" Access ===
    132 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.
    134 Additionally, there is a safety net built into the mercurial-server configuration.  In `/etc/mercurial-server` on 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.
    136 === How the email and CIA notification works ===
    13740As detailed below, we use slightly modified versions of the notify and hgcia hooks that are distributed with hg.  They are modified in order to support notification for multiple repositories without triggering duplicate notifications as the same revisions are pushed between various repositories on the server.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!