documentation: Update access control for new ref syntaxes

We now support ${username} variables and regular expressions,
so try to document their use a bit.

Change-Id: I3c42fd59b00094eee745de827055794823021618
Signed-off-by: Shawn O. Pearce <sop@google.com>
This commit is contained in:
Shawn O. Pearce 2010-07-15 11:42:34 -07:00
parent f14ada51fa
commit 6d6d451ce6

View File

@ -135,10 +135,22 @@ Reference-level access control is also possible.
Permissions can be set on a single reference name to match one
branch (e.g. `refs/heads/master`), or on a reference namespace
(e.g. `refs/heads/*`) to match any branch starting with that
prefix. So a permission with `refs/heads/*` will match
(e.g. `refs/heads/\*`) to match any branch starting with that
prefix. So a permission with `refs/heads/\*` will match
`refs/heads/master` and `refs/heads/experimental`, etc.
Reference names can also be described with a regular expression
by prefixing the reference name with `\^`. For example
`\^refs/heads/[a-z]\{1,8\}` matches all lower case branch names
between 1 and 8 characters long. Within a regular expression `.`
is a wildcard matching any character, but may be escaped as `\.`.
References can have the current user name automatically included,
creating dynamic access controls that change to match the currently
logged in user. For example to provide a personal sandbox space
to all developers, `refs/heads/sandbox/$\{username\}/*` allowing
the user 'joe' to use 'refs/heads/sandbox/joe/foo'.
When evaluating a reference-level access right, Gerrit will use
the full set of access rights to determine if the user
is allowed to perform a given action. For example, if a user is a