IBR runs a Subversion server that hosts many Subversion repositories for projects, software, papers, etc. Staff members can browse all repositories (including GIT repositories) at https://svn.ibr.cs.tu-bs.de. Those repositories that are configured for anonymous read-only access can be used via http://svn.ibr.cs.tu-bs.de/repository-name. Authenticated accesss via https://svn.ibr.cs.tu-bs.de/repository-name is required for protected repositories and all kinds of write access. There is a lot of documentation on the web. Access Control We have a method that allow repository maintainers to configure access rules themselves: Whenever a directory contains a file named .svnaccess it gets treated by the server as part of the central authorization file applied to the directory where it is located. The only special path for which different access rules can be applied in the .svnaccess file is the .svnaccess file itself. Another specific section can be given to make the server send mails upon commits. Example:
# only project members may write files
steinb = rw
timm = rw
# other staff members can only read files
@mitarb = r
# others and anonymous svn users cannot read anything
* =
[.svnaccess]
# only one user can configure access control
# others cannot even read/checkout the .svnaccess file
steinb = rw
* =
[notify]
# send emails upon commit to local and external users
steinb
nobody@example.com
Notes- The default for each path, i.e. the access permissions when no
.svnaccess Exists, is derived from the parent directory. - If the root directory of a repository does not contain a
.svnaccess file, a default applies, where all staff members (group "mitarb") have read/write access. - It is possible that a project maintainer removes his/her own access permissions from a path. Take care! If that happens you have to bring some chocolate to the admin. It is a good idea to always have something like "
myusername = rw" on the first line of the file (and on the first line of the [.svnaccess] section if it exists), even if subsequent group-based rules would match the maintainer. - The syntax is quite strict: user and group names and permissions are case-sensitive, there must be no additional white space, "
r" and "rw" must be written this way (not read or r/w). - Svn commit transactions that change
.svnaccess files may take a long time, because the server has to update its central authorization file. Do not interrupt these transactions. Otherwise you might experience an unexpectedly required update/commit cycle. - Errors in the file (syntax errors, references to non-existent groups, etc.) are not signalled to the user and the affected lines are silently dropped from the
.svnaccess file.
|
