Version 8 (modified by 12 years ago) (diff) | ,
---|
Using Pidgin Mercurial
This page is intended to house documentation for using Pidgin's Mercurial repositories once we switch from Monotone to Mercurial.
Background
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.
Anonymous Pull (Non-Developers)
All Pidgin Mercurial repositories will be available via HTTP from http://hg.pidgin.im.
Developers
Configure Mercurial
Mercurial uses an rc file to control its configuration. There are several that will affect your use. One set of them is in /etc/mercurial
and will be controlled by your package manager. The others are entirely under your control. Each repository has its own hgrc
file in repository/.hg/hgrc
which can be used to configure mercurial's behavior when interacting with that repository. Finally, there is ~/.hgrc
, which will configure mercurial's behavior for any repository your user account touches.
When working with Pidgin's mercurial repositories, we expect that you will have at least a minimum configuration that gives your name in the 'First Last <email@…>' format. To do that, two simple lines need to be inserted into an appropriate hgrc
(I believe most people will want to do this in ~/.hgrc
):
[ui] username = First Last <email@address.tld>
Other useful options that can be set in the [ui]
section of an hgrc
are the merge tool and to make mercurial verbose or not:
[ui] username = First Last <email@address.tld> verbose = True merge = meld
Git diffs can be useful too, and making hg log -v
the default behavior for hg log
can be helpful:
[diff] git = 1 [defaults] log = -v
Configure SSH For Access (Developers/CPW's/SoC Students Only)
If you wish, you can simplify Mercurial ssh: URL's by adding the following to ~/.ssh/config
:
Host hg.pidgin.im Protocol 2 User hg
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
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:
- With SSH config above:
default-push ssh://hg.pidgin.im/path/to/repo
- Without SSH config above:
default-push ssh://hg@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
Administration
Access Control
Access control on Pidgin's Mercurial server is strict. The repositories will be 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 # replaces im.pidgin.pidgin in Monotone | + 2_x_y # replaces im.pidgin.pidgin.2.x.y in Monotone + dev # Developers' repositories | + darkrain # for all repositories darkrain wishes to create | | + irc # replaces im.pidgin.cpw.darkrain42.irc in Monotone | | + xmpp_roster # replaces im.pidgin.cpw.darkrain42.xppp.roster in Monotone | + rekkanoryo # for all repositories rekkanoryo wishes to create | + examples # replaces im.pidgin.cpw.rekkanoryo.examples in Monotone + cpw # Crazy Patch Writers' repositories | + eionrobb # for all repositories eionrobb wishes to create | + newfeature # new repository + www # For websites | + pidgin # for pidgin.im | + imfreedom # for imfreedom.org + soc # For Google Summer of Code projects (lines below should be obvious) + 2007 | + student1 | + project1 + ... + 2012 + studentx + projectx
Access control will be as follows:
- Developers 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/*
- 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.
- Those people with "root" access can do anything to any repository. This access is strictly controlled.
Adding New Users
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, rekkanoryo, and lschiere.
- Check out the
hgadmin
repo:hg clone ssh://hg@hg.pidgin.im/hgadmin pidgin-hgadmin
cd pidgin-hgadmin/keys
. Inhere is a series of directories. The format is self-explaining. Developers go indevs/$NICKNAME
, CPW's incpws/$NICKNAME
, SoC students insoc/$NICKNAME
. This is to allow a single developer, CPW, or SoC student to have multiple SSH keys, perhaps for multiple machines.- Create the appropriate directory.
- Within this directory create a file named for the SSH key being added, for example
user@somehost
. - Put the SSH public key in this file.
hg add $FILE
- Go back to the root of
pidgin-hgadmin
. - 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. hg commit
hg push
(mercurial-server updates automatically on push)
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.
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.
Hooks / Extensions
There are a number of hooks, extensions and other configuration in place for the various repositories:
Hooks
- pushlog.py tweaked version of a mozilla hook to keep track of who pushed a particular revision
- This is registered globally as
'changelog.pushlog'
for both thehg
user and mercurial-server
- This is registered globally as
- author_email_hook.py verify that incoming commit authors are in the form of an email address -
'user@domain.tld'
or'User Name <user@domain.tld>'
- This is registered globally as
'pretxnchangegroup.authorcheck'
for both thehg
user and mercurial-server
- This is registered globally as
- notify_repo_sync.sh trigger a sync in the background with the notification repo to trigger email and cia notifications
- This is registered globally as
'changegroup.notify_sync'
for both thehg
user and mercurial-server - Note: an initial manual pull may be necessary for new repos
- This is registered globally as
- notify.py slightly tweaked version of the built-in hg hook to facilitate using a separate repo for driving the notifications
- This is registered in the
/srv/mercurial-server/notification-repo/
(which isn't served anywhere)
- This is registered in the
- hgcia.py slightly tweaked version of the built-in hg hook for CIA bot notification
- This is registered in the
/srv/mercurial-server/notification-repo/
(which isn't served anywhere)
- This is registered in the
hgweb stuff
- pushlog extension extension to expose pushlog information gathered by the hook to hgweb
- hgweb templates slightly tweaked vanilla templates to add pushlog