Access to much of this site depends firstly on authentication of your credentials, which identifies you as a particular user, and then checking your authorization, i.e., whether you are allowed to perform specific operations on specific folders, as determined by its permissions.

Note that some folders may permit anonymous access, where you don't have to authenticate first.

To request authorization, contact an administrator of the folders you wish to access.


A user can be a member of zero or more named groups. Groups can also be members of other groups, although loops are not permitted.

Each group is owned by a group. Members of the owning group can alter the membership of the owned group. A group can own more than one group, and can even own itself.

To create a group, you must belong to its would-be owner. This means that anyone can create any number of groups, but note that groups don't persist more than 24 hours unless they are referenced by a rule or a domain.

Special groups

There are a few groups with special purpose.

may make any changes.

Repository makers S may create repositories (SVN) (Git)  S.

User administrators S may create courtesy accounts S.

SVN authorization

Folder operations

There are three kinds of operation you can perform on a repository folder, and correspondingly three kinds of permission a user can be granted:

  • Read operations include checkouts, updates, exports and browsing.

  • Write operations are imports and commits, including creation and deletion of folders and files.

  • Administrative operations include altering the permissions of folders, configuring hooks, and migrating to or from other repositories.

Permission to read or write a folder can be granted at one level of the folder's ancestry, and revoked at a lower level. Permission to administrate a folder cannot be withdrawn at lower levels.


A ruleset is a set of rules applied to a folder. Folders and their rulesets are identified by their path within a repository, and optionally by the name of the repository. If a repository is not specified, the ruleset applies to the same path in all repositories. (This is referred to as a wildcard ruleset.)

For example, the notation enthrone:/libeqos/ identifies a ruleset with the path /libeqos/ in the repository enthrone. The notation /libeqos/ identifies a ruleset with the path /libeqos/, applicable to all repositories.

One ruleset, with a path that is a prefix of the path of a second ruleset, is less specific than the second, even if the first specifies a repository but the second doesn't. If two rulesets specify the same path, but one specifies a repository and the other doesn't, the latter is less specific.

For example, enthrone:/libeqos/trunk/ is more specific than /libeqos/trunk/, which itself is more specific than enthrone:/libeqos/.

The ancestry of a ruleset is the sequence of rulesets that are gradually less specific than it. Consider this list of decreasingly specific ruleset identifiers:

  • enthrone:/libeqos/trunk/
  • /libeqos/trunk/
  • enthrone:/libeqos/
  • /libeqos/
  • enthrone:/
  • /

A ruleset matches a user if at least one of its rules matches that user. To determine read/write authorization for a user on a particular folder, the ruleset for that folder is consulted, then the next in its ancestry, and so on, until a matching ruleset is found. For administration, the search continues to the root, even if a ruleset has already matched without granting that permission.

Folder rules

Each rule identifies a party and a set of permissions to grant to it.

Parties are identified by a rule in three ways:

  • By username.

  • By group name.

  • By wildcard.

If at least one rule in a ruleset matches a user, the union of the permissions of all matching rules in that ruleset may be applied to that user.


Party Permissions
Read Write Admin
User pillock No No No
Group users Yes No No
Group developers Yes Yes No
Group bosses No No Yes

Considering only read and write permissions, this ruleset means that:

  • The user pillock has does not have read permission on this folder, unless he belongs to users or developers.

  • The user pillock has does not have write permission on this folder, unless he belongs to developers.

  • All members of users and all members of developers have read permission.

  • All members of developers have write permission.

These permissions are only granted for folders matching this ruleset, including subfolders, but only until more specific rulesets with matching rules can be found.

Now considering the administrative permission, members of bosses have it, and continue to have it for all subfolders. None of the rules grant it to anyone else, but they may have inherited it from less specific rulesets.

Git authorization

Git authorization distinguishes between several types of write operations, and is determined by domains. FF permits simple fast-forward pushes. REW permits simple rewind pushes. M permits more complex merges in combination with FF and REW. C permits creation of branches. D permits deletion of branches. These options apply to specific sets of branches identified by regular expression. Read permission applies to the whole repository, and cannot be restricted to specific branches.

Three more permissions exist for Git repositories. REQ allows a user to initiate a pull/merge request to the specified branches. REV causes the specified users to take part in email discussions on an existing request to the specified branches. OBS causes the specified users to take part in email discussions on an existing request from the specified branches.

To determine whether a user has write access to a branch in a Git repository, identify all Git rules in its associated domain that match the user and branch. If no rule matches, recursively consult the rules of the first imported domain, with depth-first traversal. Still if no rule matches, consult the second imported domain, etc.

Related pages

Lancaster University
© School of Computing and Communications, Lancaster University – Disclaimer & copyright
Some images from PixelMixer