| Index: hooks/pre-commit.tmpl |
| — | — | @@ -0,0 +1,81 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# PRE-COMMIT HOOK
|
| | 5 | +#
|
| | 6 | +# The pre-commit hook is invoked before a Subversion txn is
|
| | 7 | +# committed. Subversion runs this hook by invoking a program
|
| | 8 | +# (script, executable, binary, etc.) named 'pre-commit' (for which
|
| | 9 | +# this file is a template), with the following ordered arguments:
|
| | 10 | +#
|
| | 11 | +# [1] REPOS-PATH (the path to this repository)
|
| | 12 | +# [2] TXN-NAME (the name of the txn about to be committed)
|
| | 13 | +#
|
| | 14 | +# [STDIN] LOCK-TOKENS ** the lock tokens are passed via STDIN.
|
| | 15 | +#
|
| | 16 | +# If STDIN contains the line "LOCK-TOKENS:\n" (the "\n" denotes a
|
| | 17 | +# single newline), the lines following it are the lock tokens for
|
| | 18 | +# this commit. The end of the list is marked by a line containing
|
| | 19 | +# only a newline character.
|
| | 20 | +#
|
| | 21 | +# Each lock token line consists of a URI-escaped path, followed
|
| | 22 | +# by the separator character '|', followed by the lock token string,
|
| | 23 | +# followed by a newline.
|
| | 24 | +#
|
| | 25 | +# The default working directory for the invocation is undefined, so
|
| | 26 | +# the program should set one explicitly if it cares.
|
| | 27 | +#
|
| | 28 | +# If the hook program exits with success, the txn is committed; but
|
| | 29 | +# if it exits with failure (non-zero), the txn is aborted, no commit
|
| | 30 | +# takes place, and STDERR is returned to the client. The hook
|
| | 31 | +# program can use the 'svnlook' utility to help it examine the txn.
|
| | 32 | +#
|
| | 33 | +# On a Unix system, the normal procedure is to have 'pre-commit'
|
| | 34 | +# invoke other programs to do the real work, though it may do the
|
| | 35 | +# work itself too.
|
| | 36 | +#
|
| | 37 | +# *** NOTE: THE HOOK PROGRAM MUST NOT MODIFY THE TXN, EXCEPT ***
|
| | 38 | +# *** FOR REVISION PROPERTIES (like svn:log or svn:author). ***
|
| | 39 | +#
|
| | 40 | +# This is why we recommend using the read-only 'svnlook' utility.
|
| | 41 | +# In the future, Subversion may enforce the rule that pre-commit
|
| | 42 | +# hooks should not modify the versioned data in txns, or else come
|
| | 43 | +# up with a mechanism to make it safe to do so (by informing the
|
| | 44 | +# committing client of the changes). However, right now neither
|
| | 45 | +# mechanism is implemented, so hook writers just have to be careful.
|
| | 46 | +#
|
| | 47 | +# Note that 'pre-commit' must be executable by the user(s) who will
|
| | 48 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 49 | +# have filesystem-level permission to access the repository.
|
| | 50 | +#
|
| | 51 | +# On a Windows system, you should name the hook program
|
| | 52 | +# 'pre-commit.bat' or 'pre-commit.exe',
|
| | 53 | +# but the basic idea is the same.
|
| | 54 | +#
|
| | 55 | +# The hook program typically does not inherit the environment of
|
| | 56 | +# its parent process. For example, a common problem is for the
|
| | 57 | +# PATH environment variable to not be set to its usual value, so
|
| | 58 | +# that subprograms fail to launch unless invoked via absolute path.
|
| | 59 | +# If you're having unexpected problems with a hook program, the
|
| | 60 | +# culprit may be unusual (or missing) environment variables.
|
| | 61 | +#
|
| | 62 | +# Here is an example hook script, for a Unix /bin/sh interpreter.
|
| | 63 | +# For more examples and pre-written hooks, see those in
|
| | 64 | +# the Subversion repository at
|
| | 65 | +# http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/ and
|
| | 66 | +# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/
|
| | 67 | +
|
| | 68 | +
|
| | 69 | +REPOS="$1"
|
| | 70 | +TXN="$2"
|
| | 71 | +
|
| | 72 | +# Make sure that the log message contains some text.
|
| | 73 | +SVNLOOK=/usr/local/bin/svnlook
|
| | 74 | +$SVNLOOK log -t "$TXN" "$REPOS" | \
|
| | 75 | + grep "[a-zA-Z0-9]" > /dev/null || exit 1
|
| | 76 | +
|
| | 77 | +# Check that the author of this commit has the rights to perform
|
| | 78 | +# the commit on the files and directories being modified.
|
| | 79 | +commit-access-control.pl "$REPOS" "$TXN" commit-access-control.cfg || exit 1
|
| | 80 | +
|
| | 81 | +# All checks passed, so allow the commit.
|
| | 82 | +exit 0
|
| Index: hooks/pre-lock.tmpl |
| — | — | @@ -0,0 +1,71 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# PRE-LOCK HOOK
|
| | 5 | +#
|
| | 6 | +# The pre-lock hook is invoked before an exclusive lock is
|
| | 7 | +# created. Subversion runs this hook by invoking a program
|
| | 8 | +# (script, executable, binary, etc.) named 'pre-lock' (for which
|
| | 9 | +# this file is a template), with the following ordered arguments:
|
| | 10 | +#
|
| | 11 | +# [1] REPOS-PATH (the path to this repository)
|
| | 12 | +# [2] PATH (the path in the repository about to be locked)
|
| | 13 | +# [3] USER (the user creating the lock)
|
| | 14 | +# [4] COMMENT (the comment of the lock)
|
| | 15 | +# [5] STEAL-LOCK (1 if the user is trying to steal the lock, else 0)
|
| | 16 | +#
|
| | 17 | +# If the hook program outputs anything on stdout, the output string will
|
| | 18 | +# be used as the lock token for this lock operation. If you choose to use
|
| | 19 | +# this feature, you must guarantee the tokens generated are unique across
|
| | 20 | +# the repository each time.
|
| | 21 | +#
|
| | 22 | +# The default working directory for the invocation is undefined, so
|
| | 23 | +# the program should set one explicitly if it cares.
|
| | 24 | +#
|
| | 25 | +# If the hook program exits with success, the lock is created; but
|
| | 26 | +# if it exits with failure (non-zero), the lock action is aborted
|
| | 27 | +# and STDERR is returned to the client.
|
| | 28 | +
|
| | 29 | +# On a Unix system, the normal procedure is to have 'pre-lock'
|
| | 30 | +# invoke other programs to do the real work, though it may do the
|
| | 31 | +# work itself too.
|
| | 32 | +#
|
| | 33 | +# Note that 'pre-lock' must be executable by the user(s) who will
|
| | 34 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 35 | +# have filesystem-level permission to access the repository.
|
| | 36 | +#
|
| | 37 | +# On a Windows system, you should name the hook program
|
| | 38 | +# 'pre-lock.bat' or 'pre-lock.exe',
|
| | 39 | +# but the basic idea is the same.
|
| | 40 | +#
|
| | 41 | +# Here is an example hook script, for a Unix /bin/sh interpreter:
|
| | 42 | +
|
| | 43 | +REPOS="$1"
|
| | 44 | +PATH="$2"
|
| | 45 | +USER="$3"
|
| | 46 | +
|
| | 47 | +# If a lock exists and is owned by a different person, don't allow it
|
| | 48 | +# to be stolen (e.g., with 'svn lock --force ...').
|
| | 49 | +
|
| | 50 | +# (Maybe this script could send email to the lock owner?)
|
| | 51 | +SVNLOOK=/usr/local/bin/svnlook
|
| | 52 | +GREP=/bin/grep
|
| | 53 | +SED=/bin/sed
|
| | 54 | +
|
| | 55 | +LOCK_OWNER=`$SVNLOOK lock "$REPOS" "$PATH" | \
|
| | 56 | + $GREP '^Owner: ' | $SED 's/Owner: //'`
|
| | 57 | +
|
| | 58 | +# If we get no result from svnlook, there's no lock, allow the lock to
|
| | 59 | +# happen:
|
| | 60 | +if [ "$LOCK_OWNER" = "" ]; then
|
| | 61 | + exit 0
|
| | 62 | +fi
|
| | 63 | +
|
| | 64 | +# If the person locking matches the lock's owner, allow the lock to
|
| | 65 | +# happen:
|
| | 66 | +if [ "$LOCK_OWNER" = "$USER" ]; then
|
| | 67 | + exit 0
|
| | 68 | +fi
|
| | 69 | +
|
| | 70 | +# Otherwise, we've got an owner mismatch, so return failure:
|
| | 71 | +echo "Error: $PATH already locked by ${LOCK_OWNER}." 1>&2
|
| | 72 | +exit 1
|
| Index: hooks/post-unlock.tmpl |
| — | — | @@ -0,0 +1,42 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# POST-UNLOCK HOOK
|
| | 5 | +#
|
| | 6 | +# The post-unlock hook runs after a path is unlocked. Subversion runs
|
| | 7 | +# this hook by invoking a program (script, executable, binary, etc.)
|
| | 8 | +# named 'post-unlock' (for which this file is a template) with the
|
| | 9 | +# following ordered arguments:
|
| | 10 | +#
|
| | 11 | +# [1] REPOS-PATH (the path to this repository)
|
| | 12 | +# [2] USER (the user who destroyed the lock)
|
| | 13 | +#
|
| | 14 | +# The paths that were just unlocked are passed to the hook via STDIN
|
| | 15 | +# (as of Subversion 1.2, only one path is passed per invocation, but
|
| | 16 | +# the plan is to pass all unlocked paths at once, so the hook program
|
| | 17 | +# should be written accordingly).
|
| | 18 | +#
|
| | 19 | +# The default working directory for the invocation is undefined, so
|
| | 20 | +# the program should set one explicitly if it cares.
|
| | 21 | +#
|
| | 22 | +# Because the lock has already been destroyed and cannot be undone,
|
| | 23 | +# the exit code of the hook program is ignored.
|
| | 24 | +#
|
| | 25 | +# On a Unix system, the normal procedure is to have 'post-unlock'
|
| | 26 | +# invoke other programs to do the real work, though it may do the
|
| | 27 | +# work itself too.
|
| | 28 | +#
|
| | 29 | +# Note that 'post-unlock' must be executable by the user(s) who will
|
| | 30 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 31 | +# have filesystem-level permission to access the repository.
|
| | 32 | +#
|
| | 33 | +# On a Windows system, you should name the hook program
|
| | 34 | +# 'post-unlock.bat' or 'post-unlock.exe',
|
| | 35 | +# but the basic idea is the same.
|
| | 36 | +#
|
| | 37 | +# Here is an example hook script, for a Unix /bin/sh interpreter:
|
| | 38 | +
|
| | 39 | +REPOS="$1"
|
| | 40 | +USER="$2"
|
| | 41 | +
|
| | 42 | +# Send email to interested parties, let them know a lock was removed:
|
| | 43 | +mailer.py unlock "$REPOS" "$USER" /path/to/mailer.conf
|
| Index: hooks/pre-unlock.tmpl |
| — | — | @@ -0,0 +1,63 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# PRE-UNLOCK HOOK
|
| | 5 | +#
|
| | 6 | +# The pre-unlock hook is invoked before an exclusive lock is
|
| | 7 | +# destroyed. Subversion runs this hook by invoking a program
|
| | 8 | +# (script, executable, binary, etc.) named 'pre-unlock' (for which
|
| | 9 | +# this file is a template), with the following ordered arguments:
|
| | 10 | +#
|
| | 11 | +# [1] REPOS-PATH (the path to this repository)
|
| | 12 | +# [2] PATH (the path in the repository about to be unlocked)
|
| | 13 | +# [3] USER (the user destroying the lock)
|
| | 14 | +# [4] TOKEN (the lock token to be destroyed)
|
| | 15 | +# [5] BREAK-UNLOCK (1 if the user is breaking the lock, else 0)
|
| | 16 | +#
|
| | 17 | +# The default working directory for the invocation is undefined, so
|
| | 18 | +# the program should set one explicitly if it cares.
|
| | 19 | +#
|
| | 20 | +# If the hook program exits with success, the lock is destroyed; but
|
| | 21 | +# if it exits with failure (non-zero), the unlock action is aborted
|
| | 22 | +# and STDERR is returned to the client.
|
| | 23 | +
|
| | 24 | +# On a Unix system, the normal procedure is to have 'pre-unlock'
|
| | 25 | +# invoke other programs to do the real work, though it may do the
|
| | 26 | +# work itself too.
|
| | 27 | +#
|
| | 28 | +# Note that 'pre-unlock' must be executable by the user(s) who will
|
| | 29 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 30 | +# have filesystem-level permission to access the repository.
|
| | 31 | +#
|
| | 32 | +# On a Windows system, you should name the hook program
|
| | 33 | +# 'pre-unlock.bat' or 'pre-unlock.exe',
|
| | 34 | +# but the basic idea is the same.
|
| | 35 | +#
|
| | 36 | +# Here is an example hook script, for a Unix /bin/sh interpreter:
|
| | 37 | +
|
| | 38 | +REPOS="$1"
|
| | 39 | +PATH="$2"
|
| | 40 | +USER="$3"
|
| | 41 | +
|
| | 42 | +# If a lock is owned by a different person, don't allow it be broken.
|
| | 43 | +# (Maybe this script could send email to the lock owner?)
|
| | 44 | +
|
| | 45 | +SVNLOOK=/usr/local/bin/svnlook
|
| | 46 | +GREP=/bin/grep
|
| | 47 | +SED=/bin/sed
|
| | 48 | +
|
| | 49 | +LOCK_OWNER=`$SVNLOOK lock "$REPOS" "$PATH" | \
|
| | 50 | + $GREP '^Owner: ' | $SED 's/Owner: //'`
|
| | 51 | +
|
| | 52 | +# If we get no result from svnlook, there's no lock, return success:
|
| | 53 | +if [ "$LOCK_OWNER" = "" ]; then
|
| | 54 | + exit 0
|
| | 55 | +fi
|
| | 56 | +
|
| | 57 | +# If the person unlocking matches the lock's owner, return success:
|
| | 58 | +if [ "$LOCK_OWNER" = "$USER" ]; then
|
| | 59 | + exit 0
|
| | 60 | +fi
|
| | 61 | +
|
| | 62 | +# Otherwise, we've got an owner mismatch, so return failure:
|
| | 63 | +echo "Error: $PATH locked by ${LOCK_OWNER}." 1>&2
|
| | 64 | +exit 1
|
| Index: hooks/post-revprop-change.tmpl |
| — | — | @@ -0,0 +1,56 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# POST-REVPROP-CHANGE HOOK
|
| | 5 | +#
|
| | 6 | +# The post-revprop-change hook is invoked after a revision property
|
| | 7 | +# has been added, modified or deleted. Subversion runs this hook by
|
| | 8 | +# invoking a program (script, executable, binary, etc.) named
|
| | 9 | +# 'post-revprop-change' (for which this file is a template), with the
|
| | 10 | +# following ordered arguments:
|
| | 11 | +#
|
| | 12 | +# [1] REPOS-PATH (the path to this repository)
|
| | 13 | +# [2] REV (the revision that was tweaked)
|
| | 14 | +# [3] USER (the username of the person tweaking the property)
|
| | 15 | +# [4] PROPNAME (the property that was changed)
|
| | 16 | +# [5] ACTION (the property was 'A'dded, 'M'odified, or 'D'eleted)
|
| | 17 | +#
|
| | 18 | +# [STDIN] PROPVAL ** the old property value is passed via STDIN.
|
| | 19 | +#
|
| | 20 | +# Because the propchange has already completed and cannot be undone,
|
| | 21 | +# the exit code of the hook program is ignored. The hook program
|
| | 22 | +# can use the 'svnlook' utility to help it examine the
|
| | 23 | +# new property value.
|
| | 24 | +#
|
| | 25 | +# On a Unix system, the normal procedure is to have 'post-revprop-change'
|
| | 26 | +# invoke other programs to do the real work, though it may do the
|
| | 27 | +# work itself too.
|
| | 28 | +#
|
| | 29 | +# Note that 'post-revprop-change' must be executable by the user(s) who will
|
| | 30 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 31 | +# have filesystem-level permission to access the repository.
|
| | 32 | +#
|
| | 33 | +# On a Windows system, you should name the hook program
|
| | 34 | +# 'post-revprop-change.bat' or 'post-revprop-change.exe',
|
| | 35 | +# but the basic idea is the same.
|
| | 36 | +#
|
| | 37 | +# The hook program typically does not inherit the environment of
|
| | 38 | +# its parent process. For example, a common problem is for the
|
| | 39 | +# PATH environment variable to not be set to its usual value, so
|
| | 40 | +# that subprograms fail to launch unless invoked via absolute path.
|
| | 41 | +# If you're having unexpected problems with a hook program, the
|
| | 42 | +# culprit may be unusual (or missing) environment variables.
|
| | 43 | +#
|
| | 44 | +# Here is an example hook script, for a Unix /bin/sh interpreter.
|
| | 45 | +# For more examples and pre-written hooks, see those in
|
| | 46 | +# the Subversion repository at
|
| | 47 | +# http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/ and
|
| | 48 | +# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/
|
| | 49 | +
|
| | 50 | +
|
| | 51 | +REPOS="$1"
|
| | 52 | +REV="$2"
|
| | 53 | +USER="$3"
|
| | 54 | +PROPNAME="$4"
|
| | 55 | +ACTION="$5"
|
| | 56 | +
|
| | 57 | +mailer.py propchange2 "$REPOS" "$REV" "$USER" "$PROPNAME" "$ACTION" /path/to/mailer.conf
|
| Index: hooks/start-commit.tmpl |
| — | — | @@ -0,0 +1,65 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# START-COMMIT HOOK
|
| | 5 | +#
|
| | 6 | +# The start-commit hook is invoked before a Subversion txn is created
|
| | 7 | +# in the process of doing a commit. Subversion runs this hook
|
| | 8 | +# by invoking a program (script, executable, binary, etc.) named
|
| | 9 | +# 'start-commit' (for which this file is a template)
|
| | 10 | +# with the following ordered arguments:
|
| | 11 | +#
|
| | 12 | +# [1] REPOS-PATH (the path to this repository)
|
| | 13 | +# [2] USER (the authenticated user attempting to commit)
|
| | 14 | +# [3] CAPABILITIES (a colon-separated list of capabilities reported
|
| | 15 | +# by the client; see note below)
|
| | 16 | +#
|
| | 17 | +# Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5
|
| | 18 | +# clients will typically report at least the "mergeinfo" capability.
|
| | 19 | +# If there are other capabilities, then the list is colon-separated,
|
| | 20 | +# e.g.: "mergeinfo:some-other-capability" (the order is undefined).
|
| | 21 | +#
|
| | 22 | +# The list is self-reported by the client. Therefore, you should not
|
| | 23 | +# make security assumptions based on the capabilities list, nor should
|
| | 24 | +# you assume that clients reliably report every capability they have.
|
| | 25 | +#
|
| | 26 | +# The working directory for this hook program's invocation is undefined,
|
| | 27 | +# so the program should set one explicitly if it cares.
|
| | 28 | +#
|
| | 29 | +# If the hook program exits with success, the commit continues; but
|
| | 30 | +# if it exits with failure (non-zero), the commit is stopped before
|
| | 31 | +# a Subversion txn is created, and STDERR is returned to the client.
|
| | 32 | +#
|
| | 33 | +# On a Unix system, the normal procedure is to have 'start-commit'
|
| | 34 | +# invoke other programs to do the real work, though it may do the
|
| | 35 | +# work itself too.
|
| | 36 | +#
|
| | 37 | +# Note that 'start-commit' must be executable by the user(s) who will
|
| | 38 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 39 | +# have filesystem-level permission to access the repository.
|
| | 40 | +#
|
| | 41 | +# On a Windows system, you should name the hook program
|
| | 42 | +# 'start-commit.bat' or 'start-commit.exe',
|
| | 43 | +# but the basic idea is the same.
|
| | 44 | +#
|
| | 45 | +# The hook program typically does not inherit the environment of
|
| | 46 | +# its parent process. For example, a common problem is for the
|
| | 47 | +# PATH environment variable to not be set to its usual value, so
|
| | 48 | +# that subprograms fail to launch unless invoked via absolute path.
|
| | 49 | +# If you're having unexpected problems with a hook program, the
|
| | 50 | +# culprit may be unusual (or missing) environment variables.
|
| | 51 | +#
|
| | 52 | +# Here is an example hook script, for a Unix /bin/sh interpreter.
|
| | 53 | +# For more examples and pre-written hooks, see those in
|
| | 54 | +# the Subversion repository at
|
| | 55 | +# http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/ and
|
| | 56 | +# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/
|
| | 57 | +
|
| | 58 | +
|
| | 59 | +REPOS="$1"
|
| | 60 | +USER="$2"
|
| | 61 | +
|
| | 62 | +commit-allower.pl --repository "$REPOS" --user "$USER" || exit 1
|
| | 63 | +special-auth-check.py --user "$USER" --auth-level 3 || exit 1
|
| | 64 | +
|
| | 65 | +# All checks passed, so allow the commit.
|
| | 66 | +exit 0
|
| Index: hooks/pre-revprop-change.tmpl |
| — | — | @@ -0,0 +1,66 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# PRE-REVPROP-CHANGE HOOK
|
| | 5 | +#
|
| | 6 | +# The pre-revprop-change hook is invoked before a revision property
|
| | 7 | +# is added, modified or deleted. Subversion runs this hook by invoking
|
| | 8 | +# a program (script, executable, binary, etc.) named 'pre-revprop-change'
|
| | 9 | +# (for which this file is a template), with the following ordered
|
| | 10 | +# arguments:
|
| | 11 | +#
|
| | 12 | +# [1] REPOS-PATH (the path to this repository)
|
| | 13 | +# [2] REVISION (the revision being tweaked)
|
| | 14 | +# [3] USER (the username of the person tweaking the property)
|
| | 15 | +# [4] PROPNAME (the property being set on the revision)
|
| | 16 | +# [5] ACTION (the property is being 'A'dded, 'M'odified, or 'D'eleted)
|
| | 17 | +#
|
| | 18 | +# [STDIN] PROPVAL ** the new property value is passed via STDIN.
|
| | 19 | +#
|
| | 20 | +# If the hook program exits with success, the propchange happens; but
|
| | 21 | +# if it exits with failure (non-zero), the propchange doesn't happen.
|
| | 22 | +# The hook program can use the 'svnlook' utility to examine the
|
| | 23 | +# existing value of the revision property.
|
| | 24 | +#
|
| | 25 | +# WARNING: unlike other hooks, this hook MUST exist for revision
|
| | 26 | +# properties to be changed. If the hook does not exist, Subversion
|
| | 27 | +# will behave as if the hook were present, but failed. The reason
|
| | 28 | +# for this is that revision properties are UNVERSIONED, meaning that
|
| | 29 | +# a successful propchange is destructive; the old value is gone
|
| | 30 | +# forever. We recommend the hook back up the old value somewhere.
|
| | 31 | +#
|
| | 32 | +# On a Unix system, the normal procedure is to have 'pre-revprop-change'
|
| | 33 | +# invoke other programs to do the real work, though it may do the
|
| | 34 | +# work itself too.
|
| | 35 | +#
|
| | 36 | +# Note that 'pre-revprop-change' must be executable by the user(s) who will
|
| | 37 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 38 | +# have filesystem-level permission to access the repository.
|
| | 39 | +#
|
| | 40 | +# On a Windows system, you should name the hook program
|
| | 41 | +# 'pre-revprop-change.bat' or 'pre-revprop-change.exe',
|
| | 42 | +# but the basic idea is the same.
|
| | 43 | +#
|
| | 44 | +# The hook program typically does not inherit the environment of
|
| | 45 | +# its parent process. For example, a common problem is for the
|
| | 46 | +# PATH environment variable to not be set to its usual value, so
|
| | 47 | +# that subprograms fail to launch unless invoked via absolute path.
|
| | 48 | +# If you're having unexpected problems with a hook program, the
|
| | 49 | +# culprit may be unusual (or missing) environment variables.
|
| | 50 | +#
|
| | 51 | +# Here is an example hook script, for a Unix /bin/sh interpreter.
|
| | 52 | +# For more examples and pre-written hooks, see those in
|
| | 53 | +# the Subversion repository at
|
| | 54 | +# http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/ and
|
| | 55 | +# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/
|
| | 56 | +
|
| | 57 | +
|
| | 58 | +REPOS="$1"
|
| | 59 | +REV="$2"
|
| | 60 | +USER="$3"
|
| | 61 | +PROPNAME="$4"
|
| | 62 | +ACTION="$5"
|
| | 63 | +
|
| | 64 | +if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi
|
| | 65 | +
|
| | 66 | +echo "Changing revision properties other than svn:log is prohibited" >&2
|
| | 67 | +exit 1
|
| Index: hooks/post-commit.tmpl |
| — | — | @@ -0,0 +1,50 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# POST-COMMIT HOOK
|
| | 5 | +#
|
| | 6 | +# The post-commit hook is invoked after a commit. Subversion runs
|
| | 7 | +# this hook by invoking a program (script, executable, binary, etc.)
|
| | 8 | +# named 'post-commit' (for which this file is a template) with the
|
| | 9 | +# following ordered arguments:
|
| | 10 | +#
|
| | 11 | +# [1] REPOS-PATH (the path to this repository)
|
| | 12 | +# [2] REV (the number of the revision just committed)
|
| | 13 | +#
|
| | 14 | +# The default working directory for the invocation is undefined, so
|
| | 15 | +# the program should set one explicitly if it cares.
|
| | 16 | +#
|
| | 17 | +# Because the commit has already completed and cannot be undone,
|
| | 18 | +# the exit code of the hook program is ignored. The hook program
|
| | 19 | +# can use the 'svnlook' utility to help it examine the
|
| | 20 | +# newly-committed tree.
|
| | 21 | +#
|
| | 22 | +# On a Unix system, the normal procedure is to have 'post-commit'
|
| | 23 | +# invoke other programs to do the real work, though it may do the
|
| | 24 | +# work itself too.
|
| | 25 | +#
|
| | 26 | +# Note that 'post-commit' must be executable by the user(s) who will
|
| | 27 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 28 | +# have filesystem-level permission to access the repository.
|
| | 29 | +#
|
| | 30 | +# On a Windows system, you should name the hook program
|
| | 31 | +# 'post-commit.bat' or 'post-commit.exe',
|
| | 32 | +# but the basic idea is the same.
|
| | 33 | +#
|
| | 34 | +# The hook program typically does not inherit the environment of
|
| | 35 | +# its parent process. For example, a common problem is for the
|
| | 36 | +# PATH environment variable to not be set to its usual value, so
|
| | 37 | +# that subprograms fail to launch unless invoked via absolute path.
|
| | 38 | +# If you're having unexpected problems with a hook program, the
|
| | 39 | +# culprit may be unusual (or missing) environment variables.
|
| | 40 | +#
|
| | 41 | +# Here is an example hook script, for a Unix /bin/sh interpreter.
|
| | 42 | +# For more examples and pre-written hooks, see those in
|
| | 43 | +# the Subversion repository at
|
| | 44 | +# http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/ and
|
| | 45 | +# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/
|
| | 46 | +
|
| | 47 | +
|
| | 48 | +REPOS="$1"
|
| | 49 | +REV="$2"
|
| | 50 | +
|
| | 51 | +mailer.py commit "$REPOS" "$REV" /path/to/mailer.conf
|
| Index: hooks/post-lock.tmpl |
| — | — | @@ -0,0 +1,44 @@ |
| | 2 | +#!/bin/sh
|
| | 3 | +
|
| | 4 | +# POST-LOCK HOOK
|
| | 5 | +#
|
| | 6 | +# The post-lock hook is run after a path is locked. Subversion runs
|
| | 7 | +# this hook by invoking a program (script, executable, binary, etc.)
|
| | 8 | +# named 'post-lock' (for which this file is a template) with the
|
| | 9 | +# following ordered arguments:
|
| | 10 | +#
|
| | 11 | +# [1] REPOS-PATH (the path to this repository)
|
| | 12 | +# [2] USER (the user who created the lock)
|
| | 13 | +#
|
| | 14 | +# The paths that were just locked are passed to the hook via STDIN (as
|
| | 15 | +# of Subversion 1.2, only one path is passed per invocation, but the
|
| | 16 | +# plan is to pass all locked paths at once, so the hook program
|
| | 17 | +# should be written accordingly).
|
| | 18 | +#
|
| | 19 | +# The default working directory for the invocation is undefined, so
|
| | 20 | +# the program should set one explicitly if it cares.
|
| | 21 | +#
|
| | 22 | +# Because the lock has already been created and cannot be undone,
|
| | 23 | +# the exit code of the hook program is ignored. The hook program
|
| | 24 | +# can use the 'svnlook' utility to help it examine the
|
| | 25 | +# newly-created lock.
|
| | 26 | +#
|
| | 27 | +# On a Unix system, the normal procedure is to have 'post-lock'
|
| | 28 | +# invoke other programs to do the real work, though it may do the
|
| | 29 | +# work itself too.
|
| | 30 | +#
|
| | 31 | +# Note that 'post-lock' must be executable by the user(s) who will
|
| | 32 | +# invoke it (typically the user httpd runs as), and that user must
|
| | 33 | +# have filesystem-level permission to access the repository.
|
| | 34 | +#
|
| | 35 | +# On a Windows system, you should name the hook program
|
| | 36 | +# 'post-lock.bat' or 'post-lock.exe',
|
| | 37 | +# but the basic idea is the same.
|
| | 38 | +#
|
| | 39 | +# Here is an example hook script, for a Unix /bin/sh interpreter:
|
| | 40 | +
|
| | 41 | +REPOS="$1"
|
| | 42 | +USER="$2"
|
| | 43 | +
|
| | 44 | +# Send email to interested parties, let them know a lock was created:
|
| | 45 | +mailer.py lock "$REPOS" "$USER" /path/to/mailer.conf
|
| Index: conf/authz |
| — | — | @@ -0,0 +1,32 @@ |
| | 2 | +### This file is an example authorization file for svnserve.
|
| | 3 | +### Its format is identical to that of mod_authz_svn authorization
|
| | 4 | +### files.
|
| | 5 | +### As shown below each section defines authorizations for the path and
|
| | 6 | +### (optional) repository specified by the section name.
|
| | 7 | +### The authorizations follow. An authorization line can refer to:
|
| | 8 | +### - a single user,
|
| | 9 | +### - a group of users defined in a special [groups] section,
|
| | 10 | +### - an alias defined in a special [aliases] section,
|
| | 11 | +### - all authenticated users, using the '$authenticated' token,
|
| | 12 | +### - only anonymous users, using the '$anonymous' token,
|
| | 13 | +### - anyone, using the '*' wildcard.
|
| | 14 | +###
|
| | 15 | +### A match can be inverted by prefixing the rule with '~'. Rules can
|
| | 16 | +### grant read ('r') access, read-write ('rw') access, or no access
|
| | 17 | +### ('').
|
| | 18 | +
|
| | 19 | +[aliases]
|
| | 20 | +# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average
|
| | 21 | +
|
| | 22 | +[groups]
|
| | 23 | +# harry_and_sally = harry,sally
|
| | 24 | +# harry_sally_and_joe = harry,sally,&joe
|
| | 25 | +
|
| | 26 | +# [/foo/bar]
|
| | 27 | +# harry = rw
|
| | 28 | +# &joe = r
|
| | 29 | +# * =
|
| | 30 | +
|
| | 31 | +# [repository:/baz/fuz]
|
| | 32 | +# @harry_and_sally = rw
|
| | 33 | +# * = r
|
| Index: conf/svnserve.conf |
| — | — | @@ -0,0 +1,47 @@ |
| | 2 | +### This file controls the configuration of the svnserve daemon, if you
|
| | 3 | +### use it to allow access to this repository. (If you only allow
|
| | 4 | +### access through http: and/or file: URLs, then this file is
|
| | 5 | +### irrelevant.)
|
| | 6 | +
|
| | 7 | +### Visit http://subversion.tigris.org/ for more information.
|
| | 8 | +
|
| | 9 | +[general]
|
| | 10 | +### These options control access to the repository for unauthenticated
|
| | 11 | +### and authenticated users. Valid values are "write", "read",
|
| | 12 | +### and "none". The sample settings below are the defaults.
|
| | 13 | +# anon-access = read
|
| | 14 | +# auth-access = write
|
| | 15 | +### The password-db option controls the location of the password
|
| | 16 | +### database file. Unless you specify a path starting with a /,
|
| | 17 | +### the file's location is relative to the directory containing
|
| | 18 | +### this configuration file.
|
| | 19 | +### If SASL is enabled (see below), this file will NOT be used.
|
| | 20 | +### Uncomment the line below to use the default password file.
|
| | 21 | +# password-db = passwd
|
| | 22 | +### The authz-db option controls the location of the authorization
|
| | 23 | +### rules for path-based access control. Unless you specify a path
|
| | 24 | +### starting with a /, the file's location is relative to the the
|
| | 25 | +### directory containing this file. If you don't specify an
|
| | 26 | +### authz-db, no path-based access control is done.
|
| | 27 | +### Uncomment the line below to use the default authorization file.
|
| | 28 | +# authz-db = authz
|
| | 29 | +### This option specifies the authentication realm of the repository.
|
| | 30 | +### If two repositories have the same authentication realm, they should
|
| | 31 | +### have the same password database, and vice versa. The default realm
|
| | 32 | +### is repository's uuid.
|
| | 33 | +# realm = My First Repository
|
| | 34 | +
|
| | 35 | +[sasl]
|
| | 36 | +### This option specifies whether you want to use the Cyrus SASL
|
| | 37 | +### library for authentication. Default is false.
|
| | 38 | +### This section will be ignored if svnserve is not built with Cyrus
|
| | 39 | +### SASL support; to check, run 'svnserve --version' and look for a line
|
| | 40 | +### reading 'Cyrus SASL authentication is available.'
|
| | 41 | +# use-sasl = true
|
| | 42 | +### These options specify the desired strength of the security layer
|
| | 43 | +### that you want SASL to provide. 0 means no encryption, 1 means
|
| | 44 | +### integrity-checking only, values larger than 1 are correlated
|
| | 45 | +### to the effective key length for encryption (e.g. 128 means 128-bit
|
| | 46 | +### encryption). The values below are the defaults.
|
| | 47 | +# min-encryption = 0
|
| | 48 | +# max-encryption = 256
|
| Index: conf/passwd |
| — | — | @@ -0,0 +1,8 @@ |
| | 2 | +### This file is an example password file for svnserve.
|
| | 3 | +### Its format is similar to that of svnserve.conf. As shown in the
|
| | 4 | +### example below it contains one section labelled [users].
|
| | 5 | +### The name and password for each user follow, one account per line.
|
| | 6 | +
|
| | 7 | +[users]
|
| | 8 | +# harry = harryssecret
|
| | 9 | +# sally = sallyssecret
|
| Index: db/fs-type |
| — | — | @@ -0,0 +1 @@ |
| | 2 | +fsfs |
| Index: db/format |
| — | — | @@ -0,0 +1,2 @@ |
| | 2 | +4 |
| | 3 | +layout sharded 1000 |
| Index: db/txn-current |
| — | — | @@ -0,0 +1 @@ |
| | 2 | +0 |
| Index: db/rep-cache.db |
| Cannot display: file marked as a binary type. |
| svn:mime-type = application/octet-stream |
| Property changes on: db/rep-cache.db |
| ___________________________________________________________________ |
| Added: svn:mime-type |
| 1 | 3 | + application/octet-stream |
| Index: db/revs/0/0 |
| — | — | @@ -0,0 +1,11 @@ |
| | 2 | +PLAIN |
| | 3 | +END |
| | 4 | +ENDREP |
| | 5 | +id: 0.0.r0/17 |
| | 6 | +type: dir |
| | 7 | +count: 0 |
| | 8 | +text: 0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e |
| | 9 | +cpath: / |
| | 10 | + |
| | 11 | + |
| | 12 | +17 107 |
| Index: db/txn-current-lock |
| Index: db/revprops/0/0 |
| — | — | @@ -0,0 +1,5 @@ |
| | 2 | +K 8 |
| | 3 | +svn:date |
| | 4 | +V 27 |
| | 5 | +2009-04-25T10:06:24.484375Z |
| | 6 | +END |
| Index: db/write-lock |
| Index: db/current |
| — | — | @@ -0,0 +1 @@ |
| | 2 | +0 |
| Index: db/fsfs.conf |
| — | — | @@ -0,0 +1,37 @@ |
| | 2 | +### This file controls the configuration of the FSFS filesystem.
|
| | 3 | +
|
| | 4 | +[memcached-servers]
|
| | 5 | +### These options name memcached servers used to cache internal FSFS
|
| | 6 | +### data. See http://www.danga.com/memcached/ for more information on
|
| | 7 | +### memcached. To use memcached with FSFS, run one or more memcached
|
| | 8 | +### servers, and specify each of them as an option like so:
|
| | 9 | +# first-server = 127.0.0.1:11211
|
| | 10 | +# remote-memcached = mymemcached.corp.example.com:11212
|
| | 11 | +### The option name is ignored; the value is of the form HOST:PORT.
|
| | 12 | +### memcached servers can be shared between multiple repositories;
|
| | 13 | +### however, if you do this, you *must* ensure that repositories have
|
| | 14 | +### distinct UUIDs and paths, or else cached data from one repository
|
| | 15 | +### might be used by another accidentally. Note also that memcached has
|
| | 16 | +### no authentication for reads or writes, so you must ensure that your
|
| | 17 | +### memcached servers are only accessible by trusted users.
|
| | 18 | +
|
| | 19 | +[caches]
|
| | 20 | +### When a cache-related error occurs, normally Subversion ignores it
|
| | 21 | +### and continues, logging an error if the server is appropriately
|
| | 22 | +### configured (and ignoring it with file:// access). To make
|
| | 23 | +### Subversion never ignore cache errors, uncomment this line.
|
| | 24 | +# fail-stop = true
|
| | 25 | +
|
| | 26 | +[rep-sharing]
|
| | 27 | +### To conserve space, the filesystem can optionally avoid storing
|
| | 28 | +### duplicate representations. This comes at a slight cost in performace,
|
| | 29 | +### as maintaining a database of shared representations can increase
|
| | 30 | +### commit times. The space savings are dependent upon the size of the
|
| | 31 | +### repository, the number of objects it contains and the amount of
|
| | 32 | +### duplication between them, usually a function of the branching and
|
| | 33 | +### merging process.
|
| | 34 | +###
|
| | 35 | +### The following parameter enables rep-sharing in the repository. It can
|
| | 36 | +### be switched on and off at will, but for best space-saving results
|
| | 37 | +### should be enabled consistently over the life of the repository.
|
| | 38 | +# enable-rep-sharing = false
|
| Index: db/min-unpacked-rev |
| — | — | @@ -0,0 +1 @@ |
| | 2 | +0 |
| Index: db/uuid |
| — | — | @@ -0,0 +1 @@ |
| | 2 | +500752fa-575d-534c-870b-53fa29b3549a |
| Index: format |
| — | — | @@ -0,0 +1 @@ |
| | 2 | +5 |
| Index: README.txt |
| — | — | @@ -0,0 +1,5 @@ |
| | 2 | +This is a Subversion repository; use the 'svnadmin' tool to examine |
| | 3 | +it. Do not add, delete, or modify files here unless you know how |
| | 4 | +to avoid corrupting the repository. |
| | 5 | + |
| | 6 | +Visit http://subversion.tigris.org/ for more information. |
| Property changes on: README.txt |
| ___________________________________________________________________ |
| Added: svn:eol-style |
| 1 | 7 | + native |
| Index: locks/db.lock |
| — | — | @@ -0,0 +1,3 @@ |
| | 2 | +This file is not used by Subversion 1.3.x or later.
|
| | 3 | +However, its existence is required for compatibility with
|
| | 4 | +Subversion 1.2.x or earlier.
|
| Index: locks/db-logs.lock |
| — | — | @@ -0,0 +1,3 @@ |
| | 2 | +This file is not used by Subversion 1.3.x or later.
|
| | 3 | +However, its existence is required for compatibility with
|
| | 4 | +Subversion 1.2.x or earlier.
|