svnacl is a subversion pre-commit hook that can be used to define permissions
on a subversion filesystem in the style of an access control list.  Users and
groups can be granted permission to add, change, and remove files and
properties on specific paths in the subversion database, providing write
restrictions that cannot be provided by the underlying filesystem.

BUILDING

There are a handful of libraries necessary to build svnacl:

   subversion 1.x
   apr >= 0.9.5 (using the version used to build subversion would probably
                 be a good idea)
   glib, 1.x or 2.x

I know that it seems silly to require two different utility libaries, glib and
apr.  The glib requirement may be removed in future versions.

svnacl uses autoconf and automake, so building is fairly straightforward; see
the output of `./configure --help' for more information.


INSTALLING

There are two basic options for installing svnacl: install it as the
pre-commit file, or call it from a wrapper script.

If svnacl is going to be your only pre-commit check for a particular
repository, it can be installed as the `pre-commit' file in the hooks
directory of your subversion repository.  In this case, the program itself
will be called by svnserve, and the permission definitions should be installed
as `svnacl.conf' in the hooks directory.

For more complicated scenarios, including sharing a config file among several
repositories, a wrapper script can be used to call svnacl and possibly perform
additional checks before and afterwards.  In this case, svnacl should be
called using something like the following:

   /path/to/svnacl -r "$1" -t "$2" -c /path/to/svnacl.conf || exit 1

$1 and $2 are the repository path and transaction name, respectively.
Subversion hooks are called without an environment, including $PATH, so the
full path to the svnacl program should always be used.


RATIONALE

Subversion is packaged with hook scripts to provide functionality similar to
that of svnacl, but I felt that they have several shortcomings:

   - There is no support for the system groups
   - They only provide two options: read-only or read-write.  No fine-tuning
     for add/change/remove (NB: this only applies to the perl
     commit-access-control, not the python svnperms)
   - Property changes are only checked in terms of what can be done to the
     file: there are no per-property definitions
   - Both provided scripts require an external interpreter and all
     accompanying libraries and support files, which is an inconvienent for a
     chrooted repository
   - Forcing users to put comments into an INI section header seems pretty
     dumb

svnacl does about the same thing as svnperms or commit-access-control, but my
hope is that it does it in a way more convienent to server administrators.  I
hope that you enjoy it.

David Shea (david@gophernet.org)