The syntax of the file is the same familiar one used by svnserve.conf and the runtime configuration files. Lines that start with a hash (#) are ignored. In its simplest form, each section names a repository and path within it, as well as the authenticated usernames are the option names within each section. The value of each option describes the user's level of access to the repository path: eitherr(read-only) orrw(read/write). If the user is not mentioned at all, no access is allowed.
To be more specific: the value of the section names is either of the form[repos-name:path]or of the form[path]. If you're using theSVNParentPathdirective, it's important to specify the repository names in your sections. If you omit them, a section such as[/some/dir]will match the path/some/dirin every repository. If you're using theSVNPathdirective, however, it's fine to only define paths in your sections—after all, there's only one repository.
[calc:/branches/calc/bug-142] harry = rw sally = r
In this first example, the userharryhas
full read and write access on the/branches/calc/bug-142directory in thecalcrepository, but the usersallyhas read-only access. Any other users
are blocked from accessing this directory.
Of course, permissions are inherited from parent to child directory. That means we can specify a subdirectory with a different access policy for Sally:
[calc:/branches/calc/bug-142] harry = rw sally = r # give sally write access only to the 'testing' subdir [calc:/branches/calc/bug-142/testing] sally = rw
Now Sally can write to thetestingsubdirectory of the branch, but can still only read other parts. Harry, meanwhile, continues to have complete read/write access to the whole branch.
It's also possible to explicitly deny permission to someone via inheritance rules, by setting the username variable to nothing:
[calc:/branches/calc/bug-142] harry = rw sally = r [calc:/branches/calc/bug-142/secret] harry =
In this example, Harry has read/write access to the entirebug-142tree, but has absolutely no access at all to thesecretsubdirectory within it.By default, nobody has any access to the repository at all. That means that if you're starting with an empty file, you'll probably want to give at least read permission to all users at the root of the repository. You can do this by using the asterisk variable (*), which means “all users”:
[/] * = r
This is a common setup; notice that no repository name is mentioned in the section name. This makes all repositories world-readable to all users. Once all users have read access to the repositories, you can give explicitrwpermission to certain users on specific subdirectories within specific repositories.
The access file also allows you to define whole groups of users, much like the Unix/etc/groupfile:
[groups] calc-developers = harry, sally, joe paint-developers = frank, sally, jane everyone = harry, sally, joe, frank, sally, jane
Groups can be granted access control just like users. Distinguish them with an “at” (@) prefix:
[calc:/projects/calc] @calc-developers = rw [paint:/projects/paint] @paint-developers = rw jane = r
Groups can also be defined to contain other groups:
[groups] calc-developers = harry, sally, joe paint-developers = frank, sally, jane everyone = @calc-developers, @paint-developers