Authorization Design for Svn Obliterate

Table of Contents

  1. Pre-obliterate hook

Introduction

Authorization is by a pre-obliterate hook which can base its decision on the user name and the details of the attempted obliteration.

A post-obliterate hook will be available for reporting or other purposes, analogous to the post-commit hook. This is not involved in authorization.

Before a normal commit, two hooks are invoked: start-commit and pre-commit, with only the list of files available to the first one and the entire content of the change available to the second one. As obliteration does not involve transmitting file contents, there is no reason to have separate start-obliterate and pre-obliterate hooks.

Pre-obliterate hook

Obliteration is authorized by a pre-obliterate hook. A pre-obliterate hook script must be installed in order to allow any obliteration at all. This hook is not installed by default.

See the template for a Unix pre-obliterate script.

The pre-obliterate hook is named 'pre-obliterate'.

The pre-obliterate hook is passed the following parameters:

  1. REPOS-PATH - the path to this repository
  2. USER - the username of the user attempting the obliteration

The pre-obliterate hook is passed the OBLITERATION SET on its standard input as one or more PATH@REV1:REV2 lines, where PATH is the path within the repository, starting with '/', and REV1 is the first and REV2 the last revision number in the range to be obliterated. (For a single revision, REV1 == REV2 and both are present.)

If the hook returns a zero exit code, the obliteration is performed. If the hook returns a non-zero exit code, the obliteration is denied and the client should display an error message and any output that the hook sent to stderr.