/usr/share/doc/mercurial-server/html/index.html

<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Sharing Mercurial repositories with mercurial-server</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div lang="en" class="article"><div class="titlepage"><div><div><h2 class="title"><a name="idp46908928"></a>Sharing Mercurial repositories with mercurial-server</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Paul</span> <span class="surname">Crowley</span></h3></div></div><div><p class="copyright">Copyright © 2008-2010 Paul Crowley, LShift Ltd</p></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="#idp46911328">About mercurial-server</a></span></dt><dt><span class="section"><a href="#idp46916816">Step by step</a></span></dt><dd><dl><dt><span class="section"><a href="#idp46920016">Initial access to mercurial-server</a></span></dt><dt><span class="section"><a href="#idp46928896">Creating repositories</a></span></dt><dt><span class="section"><a href="#idp46933408">Adding other users</a></span></dt></dl></dd><dt><span class="section"><a href="#idp46945648">Access control</a></span></dt><dd><dl><dt><span class="section"><a href="#idp46950240">Using access.conf</a></span></dt><dt><span class="section"><a href="#idp46950496">/etc/mercurial-server and hgadmin</a></span></dt><dt><span class="section"><a href="#idp47006224">File and branch conditions</a></span></dt></dl></dd><dt><span class="section"><a href="#idp47006480">In detail</a></span></dt><dd><dl><dt><span class="section"><a href="#idp47028032">How mercurial-server works</a></span></dt><dt><span class="section"><a href="#idp47035520">Security</a></span></dt><dt><span class="section"><a href="#idp47040960">Logging</a></span></dt><dt><span class="section"><a href="#idp47043856">Paths and configuration</a></span></dt><dt><span class="section"><a href="#idp47048544">License</a></span></dt><dt><span class="section"><a href="#idp47051200">Thanks</a></span></dt></dl></dd></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp46911328"></a>About mercurial-server</h2></div></div></div><p>
Home page: <a class="ulink" href="http://www.lshift.net/mercurial-server.html" target="_top">http://www.lshift.net/mercurial-server.html</a>
</p><p>
mercurial-server gives your developers remote read/write access to
centralized <a class="ulink" href="http://hg-scm.org/" target="_top">Mercurial</a>
repositories using SSH public key authentication; it provides convenient
and fine-grained key management and access control.
</p><p>
Though mercurial-server is currently targeted at Debian-based systems such
as Ubuntu, other users have reported success getting it running on other
Unix-based systems such as Red Hat. Running it on a non-Unix system such as
Windows is not supported. You will need root privileges to install it.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp46916816"></a>Step by step</h2></div></div></div><p>
mercurial-server authenticates users not using passwords but using SSH
public keys; everyone who wants access to a mercurial-server repository
will need such a key. In combination with <span class="command"><strong>ssh-agent</strong></span> (or
equivalents such as the Windows program <a class="ulink" href="http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter9.html#pageant" target="_top">Pageant</a>),
this means that users will not need to type in a password to access the
repository. If you're not familiar with SSH public keys, the <a class="ulink" href="http://sial.org/howto/openssh/publickey-auth/" target="_top">OpenSSH Public
Key Authentication tutorial</a> may be helpful.
</p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp46920016"></a>Initial access to mercurial-server</h3></div></div></div><p>
In what follows, we assume that your username is <code class="systemitem">jay</code>, that you usually sit at a machine called
<code class="systemitem">spoon</code> and you have
installed mercurial-server on <code class="systemitem">jeeves</code> using the package management system (see the README for more on installation). We assume that you have created your SSH public key, set up your SSH agent with this key, and that this key gives you access to <code class="systemitem">jeeves</code>.
</p><pre class="screen"><code class="computeroutput">jay@spoon:~$ </code><strong class="userinput"><code>ssh -A jeeves</code></strong>
<code class="computeroutput">jay@jeeves:~$ </code><strong class="userinput"><code>ssh-add -L &gt; my-key</code></strong>
<code class="computeroutput">jay@jeeves:~$ </code><strong class="userinput"><code>sudo mkdir -p /etc/mercurial-server/keys/root/jay</code></strong>
<code class="computeroutput">jay@jeeves:~$ </code><strong class="userinput"><code>sudo cp my-key /etc/mercurial-server/keys/root/jay/spoon</code></strong>
<code class="computeroutput">jay@jeeves:~$ </code><strong class="userinput"><code>sudo -u hg /usr/share/mercurial-server/refresh-auth</code></strong>
<code class="computeroutput">jay@jeeves:~$ </code><strong class="userinput"><code>exit</code></strong>
<code class="computeroutput">Connection to jeeves closed.
jay@spoon:~$ </code></pre><p>
You can now create repositories on the remote machine and have complete
read-write access to all of them.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp46928896"></a>Creating repositories</h3></div></div></div><p>
To store a repository on the server, clone it over.
</p><pre class="screen"><code class="computeroutput">jay@spoon:~$ </code><strong class="userinput"><code>cd myproj</code></strong>
<code class="computeroutput">jay@spoon:~/myproj$ </code><strong class="userinput"><code>hg clone . ssh://hg@jeeves/jays/project</code></strong>
<code class="computeroutput">searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 119 changesets with 284 changes to 61 files
jay@spoon:~/myproj$ </code><strong class="userinput"><code>hg pull ssh://hg@jeeves/jays/project</code></strong>
<code class="computeroutput">pulling from ssh://hg@jeeves/jays/project
searching for changes
no changes found
<code class="computeroutput">jay@spoon:~/myproj$ </code><strong class="userinput"><code>cd ..</code></strong>
jay@spoon:~$ </code></pre></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp46933408"></a>Adding other users</h3></div></div></div><p>
At this stage, no-one but you has any access to any repositories you
create on this system. In order to give anyone else access, you'll need a
copy of their SSH public key; we'll assume you have that key in
<code class="filename">~/sam-saucer-key.pub</code>.  To manage access, you make changes to the special <code class="filename">hgadmin</code> repository.
</p><pre class="screen"><code class="computeroutput">jay@spoon:~$ </code><strong class="userinput"><code>hg clone ssh://hg@jeeves/hgadmin</code></strong>
<code class="computeroutput">destination directory: hgadmin
no changes found
updating working directory
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
jay@spoon:~$ </code><strong class="userinput"><code>cd hgadmin</code></strong>
<code class="computeroutput">jay@spoon:~/hgadmin$ </code><strong class="userinput"><code>mkdir -p keys/users/sam</code></strong>
<code class="computeroutput">jay@spoon:~/hgadmin$ </code><strong class="userinput"><code>cp ~/sam-saucer-key.pub keys/users/sam/saucer</code></strong>
<code class="computeroutput">jay@spoon:~/hgadmin$ </code><strong class="userinput"><code>hg add</code></strong>
<code class="computeroutput">adding keys/users/sam/saucer
jay@spoon:~/hgadmin$ </code><strong class="userinput"><code>hg commit -m "Add Sam's key"</code></strong>
<code class="computeroutput">jay@spoon:~/hgadmin$ </code><strong class="userinput"><code>hg push</code></strong>
<code class="computeroutput">pushing to ssh://hg@jeeves/hgadmin
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
jay@spoon:~/hgadmin$ </code></pre><p>
Sam can now read and write to your
<code class="uri">ssh://hg@jeeves/jays/project</code> repository.
Most other changes to access control can be made simply by making and
pushing changes to <code class="filename">hgadmin</code>, and you can use Mercurial to
cooperate with other root users in the normal way.
</p><p>
If you prefer, you could give them access by
logging into <code class="systemitem">jeeves</code>,
putting the key in the right place under <code class="filename">/etc/mercurial-server/keys</code>, and re-running
<strong class="userinput"><code>sudo -u hg /usr/share/mercurial-server/refresh-auth</code></strong>.
However, using <code class="filename">hgadmin</code> is usually more convenient if you need to make more than a very few changes; it also makes it easier to share administration with others and provides a log of all changes.
</p></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp46945648"></a>Access control</h2></div></div></div><p>
Out of the box, mercurial-server supports two kinds of users: "root" users and normal users.  If you followed the steps above, you are a "root" user because your key is under <code class="filename">keys/root</code>, while the other user you gave access to is a normal user since their key is under <code class="filename">keys/users</code>.  Keys that are not in either of these directories will by default have no access to anything.
</p><p>
Root users can edit <code class="filename">hgadmin</code>, create new repositories and read and write to existing ones.  Normal users cannot access <code class="filename">hgadmin</code> or create new repositories, but they can read and write to any other repository.
</p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp46950240"></a>Using access.conf</h3></div></div></div><p>
mercurial-server offers much more fine-grained access control than this division into two classes of users.  Let's suppose you wish to give Pat access to the <code class="filename">widget</code> repository, but no other.  We first copy Pat's SSH public key into the <code class="filename">keys/pat</code> directory in <code class="filename">hgadmin</code>.  This tells mercurial-server about Pat's key, but gives Pat no access to anything because the key is not under either <code class="filename">keys/root</code> or <code class="filename">keys/users</code>.  To grant this key access, we must give mercurial-server a new access rule, so we create a file in <code class="filename">hgadmin</code> called <code class="filename">access.conf</code>, with the following contents:</p><pre class="programlisting"># Give Pat access to the "widget" repository
write repo=widget user=pat/*
</pre><p>
Pat will have read and write access to the <code class="filename">widget</code> repository as soon as we add, commit, and push these files.
</p><p>
Each line of <code class="filename">access.conf</code> has the following syntax:
</p><pre class="programlisting"><em class="replaceable"><code>rule</code></em> <em class="replaceable"><code>condition</code></em> <em class="replaceable"><code>condition...</code></em>
</pre><p>
Blank lines and lines that start with <code class="code">#</code> are ignored. Rule is
one of
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><code class="literal">init</code>: allow reads, writes, and the creation of new repositories
</li><li class="listitem"><code class="literal">write</code>: allow reads and writes
</li><li class="listitem"><code class="literal">read</code>: allow only read operations
</li><li class="listitem"><code class="literal">deny</code>: deny all requests
</li></ul></div><p>
A condition is a globpattern matched against a relative path. The two most
important conditions are
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><code class="code">user=<em class="replaceable"><code>globpattern</code></em></code>: path to the user's key
</li><li class="listitem"><code class="code">repo=<em class="replaceable"><code>globpattern</code></em></code>: path to the repository
</li></ul></div><p>
<code class="code">*</code> only matches one directory level, where <code class="code">**</code>
matches as many as you want. More precisely, <code class="code">*</code> matches zero or
more characters not including <code class="code">/</code> while <code class="code">**</code> matches
zero or more characters including <code class="code">/</code>. So
<code class="code">projects/*</code> matches <code class="filename">projects/foo</code> but not <code class="filename">projects/foo/bar</code>, while
<code class="code">projects/**</code> matches both.
</p><p>
When considering a request, mercurial-server steps through all the rules in
<code class="filename">/etc/mercurial-server/access.conf</code> and then all the
rules in <code class="filename">access.conf</code> in <code class="filename">hgadmin</code>
looking for a rule which matches on every condition. The first match
determines whether the request will be allowed; if there is no match in
either file, the request will be denied.
</p><p>
By default, <code class="filename">/etc/mercurial-server/access.conf</code> has the
following rules:
</p><pre class="programlisting">init user=root/**
deny repo=hgadmin
write user=users/**
</pre><p>
These rules ensure that root users can do any operation on any repository,
that no other users can access the <code class="filename">hgadmin</code> repository,
and that those with keys in <code class="filename">keys/users</code> can read or write to any repository
but not create repositories.  Some examples of how these rules work:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">
User <code class="filename">root/jay</code> creates a repository
<code class="filename">foo/bar/baz</code>. This matches the first
rule and so will be allowed.
</li><li class="listitem">
User <code class="filename">root/jay</code> changes repository
<code class="filename">hgadmin</code>. Again, this matches the
first rule and so will be allowed; later rules have no effect.
</li><li class="listitem">
User <code class="filename">users/sam</code> tries to read
repository <code class="filename">hgadmin</code>. This does not
match the first rule, but matches the second, and so will be denied.
</li><li class="listitem">
User <code class="filename">users/sam</code> tries to create
repository <code class="filename">sams-project</code>. This does
not match the first two rules, but matches the third; this is a
<code class="literal">write</code> rule, which doesn't grant the privilege to create
repositories, so the request will be denied.
</li><li class="listitem">
User <code class="filename">users/sam</code> writes to existing
repository <code class="filename">projects/main</code>. Again,
this matches the third rule, which allows the request.
</li><li class="listitem">
User <code class="filename">pat</code> tries to write to existing
repository <code class="filename">widget</code>. Until we change
the <code class="filename">access.conf</code> file in <code class="filename">hgadmin</code>, this will match no rule, and so will
be denied.
</li><li class="listitem">
Any request from a user whose key not under the <code class="filename">keys</code> directory at all will always be denied,
no matter what rules are in effect; because of the way SSH authentication
works, they will be prompted to enter a password, but no password will
work. This can't be changed.
</li></ul></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp46950496"></a>/etc/mercurial-server and hgadmin</h3></div></div></div><p>
mercurial-server consults two distinct locations to collect information about what to allow: <code class="filename">/etc/mercurial-server</code> and its own <code class="filename">hgadmin</code> repository.  This is useful for several reasons:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">
Some users may not need the convenience of access control via mercurial; for these users updating <code class="filename">/etc/mercurial-server</code> may offer a simpler route.
</li><li class="listitem"><code class="filename">/etc/mercurial-server</code> is suitable
for management with tools such as <a class="ulink" href="http://reductivelabs.com/products/puppet" target="_top">Puppet</a></li><li class="listitem">
If a change to <code class="filename">hgadmin</code> leaves you "locked out", <code class="filename">/etc/mercurial-server</code> allows you a way back in.
</li><li class="listitem">
At install time, all users are "locked out", and so some mechanism to allow some users in is needed.
</li></ul></div><p>
Rules in <code class="filename">/etc/mercurial-server/access.conf</code> are checked before those in <code class="filename">hgadmin</code>, and keys in <code class="filename">/etc/mercurial-server/keys</code> will be present no matter how <code class="filename">hgadmin</code> changes.
</p><p>
We anticipate that once mercurial-server is successfully installed and
working you will usually want to use <code class="filename">hgadmin</code> for most
access control tasks. Once you have the right keys and
<code class="filename">access.conf</code> set up in <code class="filename">hgadmin</code>, you
can delete <code class="filename">/etc/mercurial-server/access.conf</code> and all
of <code class="filename">/etc/mercurial-server/keys</code>,
turning control entirely over to <code class="filename">hgadmin</code>.
</p><p>
<code class="filename">/etc/mercurial-server/remote-hgrc.d</code> is in the
<code class="systemitem">HGRCPATH</code> for all remote access to mercurial-server
repositories. This directory contains the hooks that mercurial-server uses for
access control and logging. You can add hooks to this directory, but obviously
breaking the existing hooks will disable the relevant functionality and
isn't advisable.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp47006224"></a>File and branch conditions</h3></div></div></div><p>
mercurial-server supports file and branch conditions, which restrict an
operation depending on what files it modifies and what branch the work is
on. </p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3>
The way these conditions work is subtle and can be counterintuitive. Unless
you need what they provide, ignore this section, stick to user and repo
conditions, and then things are likely to work the way you would expect. If
you do need what they provide, read what follows very carefully.
</div><p>
File and branch conditions are added to the conditions against which a rule
matches, just like user and repo conditions; they have this form:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><code class="code">file=<em class="replaceable"><code>globpattern</code></em></code>: file within the repo
</li><li class="listitem"><code class="code">branch=<em class="replaceable"><code>globpattern</code></em></code>: Mercurial branch name
</li></ul></div><p>
However, in order to understand what effect adding these conditions will
have, it helps to understand how and when these rules are applied.
</p><p>
The rules file is used to make three decisions:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">
Whether to allow a repository to be created
</li><li class="listitem">
Whether to allow any access to a repository
</li><li class="listitem">
Whether to allow a changeset
</li></ul></div><p>
When the first two of these decisions are being made, nothing is known
about any changsets that might be pushed, and so all file and branch
conditions automatically succeed for the purpose of such decisions. For the
third condition, every file changed in the changeset must be allowed by a
<code class="literal">write</code> or <code class="literal">init</code> rule for the changeset
to be allowed.
</p><p>
This means that doing tricky things with file conditions can have
counterintuitive consequences:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>You cannot limit read access to a subset of a repository with a <code class="literal">read</code>
rule and a file condition: any user who has access to a repository can read
all of it and its full history. Such a rule can only have the effect of
masking a later <code class="literal">write</code> rule, as in this example:</p><pre class="programlisting">read repo=specialrepo file=dontwritethis
write repo=specialrepo
</pre><p>
allows all users to read <code class="literal">specialrepo</code>, and to write to all files
<span class="emphasis"><em>except</em></span> that any changeset which writes to
<code class="filename">dontwritethis</code> will be rejected.
</p></li><li class="listitem">
For similar reasons, don't give <code class="literal">init</code> rules file conditions.
</li><li class="listitem"><p>Don't try to deny write access to a particular file on a particular
branch&#8212;a developer can write to the file on another branch and then merge
it in. Either deny all writes to the branch from that user, or allow them
to write to all the files they can write to on any branch.
</p><pre class="programlisting">write user=docs/* branch=docs file=docs/*
</pre><p>
This rule grants users whose keys are in the <code class="filename">docs</code> subdirectory the power to push changesets
into any repository only if those changesets are on the
<code class="literal">docs</code> branch and they affect only those files directly
under the <code class="filename">docs</code> directory. However,
the rules below have more counterintuitive consequences.
</p><pre class="programlisting">write user=docs/* branch=docs
write user=docs/* file=docs/*
read user=docs/*
</pre><p>
These rules grant users whose keys are in the <code class="filename">docs</code> subdirectory the power to change any file directly under the <code class="filename">docs</code> directory, or any file at all in the <code class="literal">docs</code> branch.  Indirectly, however, this adds up to the power to change any file on any branch, simply by making the change on the docs branch and then merging the change into another branch.
</p></li></ul></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp47006480"></a>In detail</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp47028032"></a>How mercurial-server works</h3></div></div></div><p>
All of the repositories controlled by mercurial-server are owned by a
single user, the <code class="systemitem">hg</code> user, which is why all URLs for
mercurial-server repositories start with <code class="uri">ssh://hg@...</code>.
Each SSH key that has access to the repository has an entry in
<code class="filename">~hg/.ssh/authorized_keys</code>; this is how the SSH daemon
knows to give that key access. When the user connects over SSH, their
commands are run in a custom restricted shell; this shell knows which key
was used to connect, determines what the user is trying to do, checks the
access rules to decide whether to allow it, and if allowed invokes
Mercurial internally, without forking.
</p><p>
This restricted shell also ensures that certain Mercurial extensions are
loaded when the user acts on a repository; these extensions check the
access control rules for any changeset that the user tries to commit, and
log all pushes and pulls into a per-repository access log.
</p><p>
<span class="command"><strong>refresh-auth</strong></span> recurses through the <code class="filename">/etc/mercurial-server/keys</code> and the <code class="filename">keys</code> directory in the
<code class="filename">hgadmin</code> repository, creating an entry in
<code class="filename">~hg/.ssh/authorized_keys</code> for each one. This is redone
automatically whenever a change is pushed to <code class="filename">hgadmin</code>.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp47035520"></a>Security</h3></div></div></div><p>
mercurial-server relies entirely on <span class="command"><strong>sshd</strong></span> to grant access to remote users.
As a result, it runs no daemons, installs no setuid programs, and no part
of it runs as <code class="systemitem">root</code> except the install process: all programs run as the user
<code class="systemitem">hg</code>. Any attack on mercurial-server can only be started if the attacker
already has a public key in <code class="filename">~hg/.ssh/authorized_keys</code>,
otherwise <span class="command"><strong>sshd</strong></span> will bar the way.
</p><p>
No matter what command the user tries to run on the remote system via SSH,
mercurial-server is run. It parses the command line the user asked for, and
interprets and runs the corresponding operation itself if access is
allowed, so users can only read and add to history within repositories;
they cannot run any other command. In addition, every push and pull is
logged with a datestamp, changeset ID and the key that performed the
operation.
</p><p>
However, while the first paragraph holds no matter what bugs
mercurial-server contains, the second depends on the relevant code being
correct; though the entire codebase is short, like all software mercurial-server may harbour bugs. Backups are essential!
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp47040960"></a>Logging</h3></div></div></div><p>
Every successful access is logged in a file called
<code class="filename">~hg/repos/<em class="replaceable"><code>repository</code></em>/.hg/mercurial-server.log</code>. This file is in YAML format for easy parsing, but if you don't like YAML, simply treat each line as a JSON data structure prepended with <code class="code">- </code>. The log records the time as a
UTC ISO 8601 time, the operation ("push" or "pull"), the path to the key as
used in the access rules, the SSH connection information (including the source IP address), and the hex changeset IDs.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp47043856"></a>Paths and configuration</h3></div></div></div><p>
For security reasons, all mercurial-server code runs as the <code class="systemitem">hg</code> user.  The first thing this code reads when it starts is <code class="filename">~hg/.mercurial-server</code>; if this file is absent or corrupt the code won't run.  This file specifies all of the file paths that mercurial-server uses.  In particular, it specifies that mercurial-server always uses <code class="code">HGRCPATH = /etc/mercurial-server/remote-hgrc.d</code> for remote operations, overriding any system <code class="code">HGRCPATH</code>.
</p><p>
By creating such a file with suitable entries, you can run mercurial-server as a user other than <code class="systemitem">hg</code>, or install it without root privileges; however I strongly recommend that if you need to do this, you use a user account that is used for no other purpose, and take the time to thoroughly understand how mercurial-server works before you attempt it.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp47048544"></a>License</h3></div></div></div><p>
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.
</p><p>
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
</p><p>
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc., 51
Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp47051200"></a>Thanks</h3></div></div></div><p>
Thanks for reading this far. If you use mercurial-server, please tell me about
it.
</p><p>
Paul Crowley, <code class="email">&lt;<a class="email" href="mailto:paul@lshift.net">paul@lshift.net</a>&gt;</code>, 2010
</p></div></div></div></body></html>
mercurial-server 1.2-2.2 / usr / share / doc / mercurial-server / html / index.html
