hgkeeper is an server for [mercurial](https://www.mercurial-scm.org/)

repositories. It provides access control for SSH access.

This project is brand new and not even functional yet... But if you're

interested in helping, please do!!

hgkeeper has a couple modes of operation but `serve` is the main mode.

The `setup` command is used to bootstrap hgkeeper. It will create the

directory for the repositores, the hgkeeper repository, and create an initial

`access.yml`.

The `serve` command is the main mode of operation which is to provide access to

the repositories.

Controlling access to the repositories is done via the `hgkeeper` repository.

The repository has a specific layout to make it easier to reason about.

The keys directory contains a list of files that contain one or many SSH public

keys. It is entirely up to you on how to name these files and their contents,

but note that the filename is used in `access.yml` to delegate permissions.

`access.yml` is the access control configuration. When you initial setup

`hgkeeper` you will get an `access.yml` like the following.

There's a lot going on here, so let's talk about the basics here first. Access

is granted to user via the file name in the `keys/` directory or the name of a

group.

The `groups` section contains the name of the group and the list of keys that

are in that group. So in the above example, the `admins` group has one file

who's keys will be put into the `admins` group. You can add a group to another

group. There is also a special built-in group named `public` which will allow

anyone to access the repository.

Now that we have a basic understanding of how keys are specified, we can cover

how to grant and revoke their permissions to specific repositories.

The `global` and `patterns` sections use a simple format to specify a list of

which keys are allowed to init (create), read, and write repositories.

The `global` section contains the defaults for all repositories. In the above

example, it gives permission to `admins` to create repositories anywhere and

allows all users to read all repositories. These permissions will be used

only if a repository's matching pattern does not specify a value for this

field.

The `patterns` section uses a key of a glob of what repositories to apply

these changes to. Since this is a glob pattern, that means it'll allow `*`

and `?` for wildcards. If an entry in a `patterns` entry does not specify

any of the init, read, and/or write permissions, the corresponding value from

the global section will be used.