The entry point for ?RepoGuard is the capability of Subversion to support hook scripts which are called when specific events are triggered by the repository. There are nine different kinds of hook scripts, three deal with the commit process, two with the change of revision properties and four with the handling of locks. For a complete reference of the hook scripts take a look at the "Repository Hooks" chapter in the Subversion manual. For now it is enough to know about the pre-commit and post-commit hook.
The pre-commit script is called whenever a user wants to commit his changes to the repository. A complete snapshot of how the repository would look after this commit, a so called transaction, is made. The transaction also includes information about the author of the commit, the commit message and a list of changed files. You can perform checks on this transaction and reject it if doesn't conform to your rules.
The post-commit script is called whenever a transaction was completed and a new revision exists. A revision contains the same information as a transaction with the minor difference that the revision was already committed and can't be undone anymore. But you still might want to send a log message containing a list of all changed files to a mailing list for example.
In the following the term transaction will be used for both, a real transaction and a revision, since the ?RepoGuard provides an abstraction layer which handles both cases uniformly. Based on this transaction a list of checks, e.g. code convention examination, verification of access rights or validation of the commit message, can be performed. Each check returns an exit code, which is zero for success and bigger than zero for failure, and a message including further details.
After each check was performed, the message, the exit code and the transaction are passed to the configured handlers. A handler is an extension which processes the output of the checks, e.g. it can send mails, create a log file or print the output to the console.
The configuration of the ?RepoGuard is very flexible. You can define the checks for the pre-commit and post-commit cases and a list of handlers for each check. Furthermore each check and handler has access to the configuration for its own purpose. If you use ?RepoGuard for more than one repository you can define a global system configuration with fixed values which cannot be overwritten by the local configuration in each repository. For bigger repositories you can configure different profiles affecting different parts of the repository. Each profile can have its own configuration and share some default values with the other profiles. One use-case may be stricter checks for the trunk and laxer rules for branches.