Subversion Repositories Projects

Compare Revisions

Ignore whitespace Rev 1195 → Rev 1196

/FollowMe/README.txt
0,0 → 1,9
This is a Subversion repository; use the 'svnadmin' tool to examine
it. Do not add, delete, or modify files here unless you know how
to avoid corrupting the repository.
 
The directory "db" contains a Berkeley DB environment.
you may need to tweak the values in "db/DB_CONFIG" to match the
requirements of your site.
 
Visit http://subversion.tigris.org/ for more information.
/FollowMe/conf/authz
0,0 → 1,32
### This file is an example authorization file for svnserve.
### Its format is identical to that of mod_authz_svn authorization
### files.
### As shown below each section defines authorizations for the path and
### (optional) repository specified by the section name.
### The authorizations follow. An authorization line can refer to:
### - a single user,
### - a group of users defined in a special [groups] section,
### - an alias defined in a special [aliases] section,
### - all authenticated users, using the '$authenticated' token,
### - only anonymous users, using the '$anonymous' token,
### - anyone, using the '*' wildcard.
###
### A match can be inverted by prefixing the rule with '~'. Rules can
### grant read ('r') access, read-write ('rw') access, or no access
### ('').
 
[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average
 
[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe
 
# [/foo/bar]
# harry = rw
# &joe = r
# * =
 
# [repository:/baz/fuz]
# @harry_and_sally = rw
# * = r
/FollowMe/conf/passwd
0,0 → 1,8
### This file is an example password file for svnserve.
### Its format is similar to that of svnserve.conf. As shown in the
### example below it contains one section labelled [users].
### The name and password for each user follow, one account per line.
 
[users]
# harry = harryssecret
# sally = sallyssecret
/FollowMe/conf/svnserve.conf
0,0 → 1,47
### This file controls the configuration of the svnserve daemon, if you
### use it to allow access to this repository. (If you only allow
### access through http: and/or file: URLs, then this file is
### irrelevant.)
 
### Visit http://subversion.tigris.org/ for more information.
 
[general]
### These options control access to the repository for unauthenticated
### and authenticated users. Valid values are "write", "read",
### and "none". The sample settings below are the defaults.
# anon-access = read
# auth-access = write
### The password-db option controls the location of the password
### database file. Unless you specify a path starting with a /,
### the file's location is relative to the directory containing
### this configuration file.
### If SASL is enabled (see below), this file will NOT be used.
### Uncomment the line below to use the default password file.
# password-db = passwd
### The authz-db option controls the location of the authorization
### rules for path-based access control. Unless you specify a path
### starting with a /, the file's location is relative to the the
### directory containing this file. If you don't specify an
### authz-db, no path-based access control is done.
### Uncomment the line below to use the default authorization file.
# authz-db = authz
### This option specifies the authentication realm of the repository.
### If two repositories have the same authentication realm, they should
### have the same password database, and vice versa. The default realm
### is repository's uuid.
# realm = My First Repository
 
[sasl]
### This option specifies whether you want to use the Cyrus SASL
### library for authentication. Default is false.
### This section will be ignored if svnserve is not built with Cyrus
### SASL support; to check, run 'svnserve --version' and look for a line
### reading 'Cyrus SASL authentication is available.'
# use-sasl = true
### These options specify the desired strength of the security layer
### that you want SASL to provide. 0 means no encryption, 1 means
### integrity-checking only, values larger than 1 are correlated
### to the effective key length for encryption (e.g. 128 means 128-bit
### encryption). The values below are the defaults.
# min-encryption = 0
# max-encryption = 256
/FollowMe/db/DB_CONFIG
0,0 → 1,64
# This is the configuration file for the Berkeley DB environment
# used by your Subversion repository.
# You must run 'svnadmin recover' whenever you modify this file,
# for your changes to take effect.
 
### Lock subsystem
#
# Make sure you read the documentation at:
#
# http://www.oracle.com/technology/documentation/berkeley-db/db/ref/lock/max.html
#
# before tweaking these values.
set_lk_max_locks 2000
set_lk_max_lockers 2000
set_lk_max_objects 2000
 
### Log file subsystem
#
# Make sure you read the documentation at:
#
# http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_lg_bsize.html
# http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_lg_max.html
# http://www.oracle.com/technology/documentation/berkeley-db/db/ref/log/limits.html
#
# Increase the size of the in-memory log buffer from the default
# of 32 Kbytes to 256 Kbytes. Decrease the log file size from
# 10 Mbytes to 1 Mbyte. This will help reduce the amount of disk
# space required for hot backups. The size of the log file must be
# at least four times the size of the in-memory log buffer.
#
# Note: Decreasing the in-memory buffer size below 256 Kbytes
# will hurt commit performance. For details, see this post from
# Daniel Berlin <dan@dberlin.org>:
#
# http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=161960
set_lg_bsize 262144
set_lg_max 1048576
#
# If you see "log region out of memory" errors, bump lg_regionmax.
# See http://www.oracle.com/technology/documentation/berkeley-db/db/ref/log/config.html
# and http://svn.haxx.se/users/archive-2004-10/1001.shtml for more.
set_lg_regionmax 131072
#
# The default cache size in BDB is only 256k. As explained in
# http://svn.haxx.se/dev/archive-2004-12/0369.shtml, this is too
# small for most applications. Bump this number if "db_stat -m"
# shows too many cache misses.
set_cachesize 0 1048576 1
#
# Disable fsync of log files on transaction commit. Read the
# documentation about DB_TXN_NOSYNC at:
#
# http://www.oracle.com/technology/documentation/berkeley-db/db/ref/log/config.html
#
# [requires Berkeley DB 4.0]
# set_flags DB_TXN_NOSYNC
#
# Enable automatic removal of unused transaction log files.
# Read the documentation about DB_LOG_AUTOREMOVE at:
#
# http://www.oracle.com/technology/documentation/berkeley-db/db/ref/log/config.html
#
# [requires Berkeley DB 4.2]
set_flags DB_LOG_AUTOREMOVE
/FollowMe/db/__db.001
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/__db.002
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/__db.003
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/__db.004
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/__db.005
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/__db.006
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/__db.register
0,0 → 1,0
X 0
/FollowMe/db/changes
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/checksum-reps
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/copies
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/format
0,0 → 1,0
4
/FollowMe/db/fs-type
0,0 → 1,0
bdb
/FollowMe/db/lock-tokens
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/locks
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/log.0000000001
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/miscellaneous
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/node-origins
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/nodes
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/representations
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/revisions
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/strings
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/transactions
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/db/uuids
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes:
Added: svn:mime-type
+application/octet-stream
\ No newline at end of property
/FollowMe/format
0,0 → 1,0
5
/FollowMe/hooks/post-commit.tmpl
0,0 → 1,50
#!/bin/sh
 
# POST-COMMIT HOOK
#
# The post-commit hook is invoked after a commit. Subversion runs
# this hook by invoking a program (script, executable, binary, etc.)
# named 'post-commit' (for which this file is a template) with the
# following ordered arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] REV (the number of the revision just committed)
#
# The default working directory for the invocation is undefined, so
# the program should set one explicitly if it cares.
#
# Because the commit has already completed and cannot be undone,
# the exit code of the hook program is ignored. The hook program
# can use the 'svnlook' utility to help it examine the
# newly-committed tree.
#
# On a Unix system, the normal procedure is to have 'post-commit'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'post-commit' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'post-commit.bat' or 'post-commit.exe',
# but the basic idea is the same.
#
# The hook program typically does not inherit the environment of
# its parent process. For example, a common problem is for the
# PATH environment variable to not be set to its usual value, so
# that subprograms fail to launch unless invoked via absolute path.
# If you're having unexpected problems with a hook program, the
# culprit may be unusual (or missing) environment variables.
#
# Here is an example hook script, for a Unix /bin/sh interpreter.
# For more examples and pre-written hooks, see those in
# the Subversion repository at
# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and
# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/
 
 
REPOS="$1"
REV="$2"
 
mailer.py commit "$REPOS" "$REV" /path/to/mailer.conf
/FollowMe/hooks/post-lock.tmpl
0,0 → 1,44
#!/bin/sh
 
# POST-LOCK HOOK
#
# The post-lock hook is run after a path is locked. Subversion runs
# this hook by invoking a program (script, executable, binary, etc.)
# named 'post-lock' (for which this file is a template) with the
# following ordered arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] USER (the user who created the lock)
#
# The paths that were just locked are passed to the hook via STDIN (as
# of Subversion 1.2, only one path is passed per invocation, but the
# plan is to pass all locked paths at once, so the hook program
# should be written accordingly).
#
# The default working directory for the invocation is undefined, so
# the program should set one explicitly if it cares.
#
# Because the lock has already been created and cannot be undone,
# the exit code of the hook program is ignored. The hook program
# can use the 'svnlook' utility to help it examine the
# newly-created lock.
#
# On a Unix system, the normal procedure is to have 'post-lock'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'post-lock' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'post-lock.bat' or 'post-lock.exe',
# but the basic idea is the same.
#
# Here is an example hook script, for a Unix /bin/sh interpreter:
 
REPOS="$1"
USER="$2"
 
# Send email to interested parties, let them know a lock was created:
mailer.py lock "$REPOS" "$USER" /path/to/mailer.conf
/FollowMe/hooks/post-revprop-change.tmpl
0,0 → 1,56
#!/bin/sh
 
# POST-REVPROP-CHANGE HOOK
#
# The post-revprop-change hook is invoked after a revision property
# has been added, modified or deleted. Subversion runs this hook by
# invoking a program (script, executable, binary, etc.) named
# 'post-revprop-change' (for which this file is a template), with the
# following ordered arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] REV (the revision that was tweaked)
# [3] USER (the username of the person tweaking the property)
# [4] PROPNAME (the property that was changed)
# [5] ACTION (the property was 'A'dded, 'M'odified, or 'D'eleted)
#
# [STDIN] PROPVAL ** the old property value is passed via STDIN.
#
# Because the propchange has already completed and cannot be undone,
# the exit code of the hook program is ignored. The hook program
# can use the 'svnlook' utility to help it examine the
# new property value.
#
# On a Unix system, the normal procedure is to have 'post-revprop-change'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'post-revprop-change' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'post-revprop-change.bat' or 'post-revprop-change.exe',
# but the basic idea is the same.
#
# The hook program typically does not inherit the environment of
# its parent process. For example, a common problem is for the
# PATH environment variable to not be set to its usual value, so
# that subprograms fail to launch unless invoked via absolute path.
# If you're having unexpected problems with a hook program, the
# culprit may be unusual (or missing) environment variables.
#
# Here is an example hook script, for a Unix /bin/sh interpreter.
# For more examples and pre-written hooks, see those in
# the Subversion repository at
# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and
# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/
 
 
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"
 
mailer.py propchange2 "$REPOS" "$REV" "$USER" "$PROPNAME" "$ACTION" /path/to/mailer.conf
/FollowMe/hooks/post-unlock.tmpl
0,0 → 1,42
#!/bin/sh
 
# POST-UNLOCK HOOK
#
# The post-unlock hook runs after a path is unlocked. Subversion runs
# this hook by invoking a program (script, executable, binary, etc.)
# named 'post-unlock' (for which this file is a template) with the
# following ordered arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] USER (the user who destroyed the lock)
#
# The paths that were just unlocked are passed to the hook via STDIN
# (as of Subversion 1.2, only one path is passed per invocation, but
# the plan is to pass all unlocked paths at once, so the hook program
# should be written accordingly).
#
# The default working directory for the invocation is undefined, so
# the program should set one explicitly if it cares.
#
# Because the lock has already been destroyed and cannot be undone,
# the exit code of the hook program is ignored.
#
# On a Unix system, the normal procedure is to have 'post-unlock'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'post-unlock' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'post-unlock.bat' or 'post-unlock.exe',
# but the basic idea is the same.
#
# Here is an example hook script, for a Unix /bin/sh interpreter:
 
REPOS="$1"
USER="$2"
 
# Send email to interested parties, let them know a lock was removed:
mailer.py unlock "$REPOS" "$USER" /path/to/mailer.conf
/FollowMe/hooks/pre-commit.tmpl
0,0 → 1,81
#!/bin/sh
 
# PRE-COMMIT HOOK
#
# The pre-commit hook is invoked before a Subversion txn is
# committed. Subversion runs this hook by invoking a program
# (script, executable, binary, etc.) named 'pre-commit' (for which
# this file is a template), with the following ordered arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] TXN-NAME (the name of the txn about to be committed)
#
# [STDIN] LOCK-TOKENS ** the lock tokens are passed via STDIN.
#
# If STDIN contains the line "LOCK-TOKENS:\n" (the "\n" denotes a
# single newline), the lines following it are the lock tokens for
# this commit. The end of the list is marked by a line containing
# only a newline character.
#
# Each lock token line consists of a URI-escaped path, followed
# by the separator character '|', followed by the lock token string,
# followed by a newline.
#
# The default working directory for the invocation is undefined, so
# the program should set one explicitly if it cares.
#
# If the hook program exits with success, the txn is committed; but
# if it exits with failure (non-zero), the txn is aborted, no commit
# takes place, and STDERR is returned to the client. The hook
# program can use the 'svnlook' utility to help it examine the txn.
#
# On a Unix system, the normal procedure is to have 'pre-commit'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# *** NOTE: THE HOOK PROGRAM MUST NOT MODIFY THE TXN, EXCEPT ***
# *** FOR REVISION PROPERTIES (like svn:log or svn:author). ***
#
# This is why we recommend using the read-only 'svnlook' utility.
# In the future, Subversion may enforce the rule that pre-commit
# hooks should not modify the versioned data in txns, or else come
# up with a mechanism to make it safe to do so (by informing the
# committing client of the changes). However, right now neither
# mechanism is implemented, so hook writers just have to be careful.
#
# Note that 'pre-commit' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'pre-commit.bat' or 'pre-commit.exe',
# but the basic idea is the same.
#
# The hook program typically does not inherit the environment of
# its parent process. For example, a common problem is for the
# PATH environment variable to not be set to its usual value, so
# that subprograms fail to launch unless invoked via absolute path.
# If you're having unexpected problems with a hook program, the
# culprit may be unusual (or missing) environment variables.
#
# Here is an example hook script, for a Unix /bin/sh interpreter.
# For more examples and pre-written hooks, see those in
# the Subversion repository at
# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and
# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/
 
 
REPOS="$1"
TXN="$2"
 
# Make sure that the log message contains some text.
SVNLOOK=/usr/bin/svnlook
$SVNLOOK log -t "$TXN" "$REPOS" | \
grep "[a-zA-Z0-9]" > /dev/null || exit 1
 
# Check that the author of this commit has the rights to perform
# the commit on the files and directories being modified.
commit-access-control.pl "$REPOS" "$TXN" commit-access-control.cfg || exit 1
 
# All checks passed, so allow the commit.
exit 0
/FollowMe/hooks/pre-lock.tmpl
0,0 → 1,71
#!/bin/sh
 
# PRE-LOCK HOOK
#
# The pre-lock hook is invoked before an exclusive lock is
# created. Subversion runs this hook by invoking a program
# (script, executable, binary, etc.) named 'pre-lock' (for which
# this file is a template), with the following ordered arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] PATH (the path in the repository about to be locked)
# [3] USER (the user creating the lock)
# [4] COMMENT (the comment of the lock)
# [5] STEAL-LOCK (1 if the user is trying to steal the lock, else 0)
#
# If the hook program outputs anything on stdout, the output string will
# be used as the lock token for this lock operation. If you choose to use
# this feature, you must guarantee the tokens generated are unique across
# the repository each time.
#
# The default working directory for the invocation is undefined, so
# the program should set one explicitly if it cares.
#
# If the hook program exits with success, the lock is created; but
# if it exits with failure (non-zero), the lock action is aborted
# and STDERR is returned to the client.
 
# On a Unix system, the normal procedure is to have 'pre-lock'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'pre-lock' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'pre-lock.bat' or 'pre-lock.exe',
# but the basic idea is the same.
#
# Here is an example hook script, for a Unix /bin/sh interpreter:
 
REPOS="$1"
PATH="$2"
USER="$3"
 
# If a lock exists and is owned by a different person, don't allow it
# to be stolen (e.g., with 'svn lock --force ...').
 
# (Maybe this script could send email to the lock owner?)
SVNLOOK=/usr/bin/svnlook
GREP=/bin/grep
SED=/bin/sed
 
LOCK_OWNER=`$SVNLOOK lock "$REPOS" "$PATH" | \
$GREP '^Owner: ' | $SED 's/Owner: //'`
 
# If we get no result from svnlook, there's no lock, allow the lock to
# happen:
if [ "$LOCK_OWNER" = "" ]; then
exit 0
fi
 
# If the person locking matches the lock's owner, allow the lock to
# happen:
if [ "$LOCK_OWNER" = "$USER" ]; then
exit 0
fi
 
# Otherwise, we've got an owner mismatch, so return failure:
echo "Error: $PATH already locked by ${LOCK_OWNER}." 1>&2
exit 1
/FollowMe/hooks/pre-revprop-change.tmpl
0,0 → 1,66
#!/bin/sh
 
# PRE-REVPROP-CHANGE HOOK
#
# The pre-revprop-change hook is invoked before a revision property
# is added, modified or deleted. Subversion runs this hook by invoking
# a program (script, executable, binary, etc.) named 'pre-revprop-change'
# (for which this file is a template), with the following ordered
# arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] REVISION (the revision being tweaked)
# [3] USER (the username of the person tweaking the property)
# [4] PROPNAME (the property being set on the revision)
# [5] ACTION (the property is being 'A'dded, 'M'odified, or 'D'eleted)
#
# [STDIN] PROPVAL ** the new property value is passed via STDIN.
#
# If the hook program exits with success, the propchange happens; but
# if it exits with failure (non-zero), the propchange doesn't happen.
# The hook program can use the 'svnlook' utility to examine the
# existing value of the revision property.
#
# WARNING: unlike other hooks, this hook MUST exist for revision
# properties to be changed. If the hook does not exist, Subversion
# will behave as if the hook were present, but failed. The reason
# for this is that revision properties are UNVERSIONED, meaning that
# a successful propchange is destructive; the old value is gone
# forever. We recommend the hook back up the old value somewhere.
#
# On a Unix system, the normal procedure is to have 'pre-revprop-change'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'pre-revprop-change' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'pre-revprop-change.bat' or 'pre-revprop-change.exe',
# but the basic idea is the same.
#
# The hook program typically does not inherit the environment of
# its parent process. For example, a common problem is for the
# PATH environment variable to not be set to its usual value, so
# that subprograms fail to launch unless invoked via absolute path.
# If you're having unexpected problems with a hook program, the
# culprit may be unusual (or missing) environment variables.
#
# Here is an example hook script, for a Unix /bin/sh interpreter.
# For more examples and pre-written hooks, see those in
# the Subversion repository at
# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and
# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/
 
 
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"
 
if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi
 
echo "Changing revision properties other than svn:log is prohibited" >&2
exit 1
/FollowMe/hooks/pre-unlock.tmpl
0,0 → 1,63
#!/bin/sh
 
# PRE-UNLOCK HOOK
#
# The pre-unlock hook is invoked before an exclusive lock is
# destroyed. Subversion runs this hook by invoking a program
# (script, executable, binary, etc.) named 'pre-unlock' (for which
# this file is a template), with the following ordered arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] PATH (the path in the repository about to be unlocked)
# [3] USER (the user destroying the lock)
# [4] TOKEN (the lock token to be destroyed)
# [5] BREAK-UNLOCK (1 if the user is breaking the lock, else 0)
#
# The default working directory for the invocation is undefined, so
# the program should set one explicitly if it cares.
#
# If the hook program exits with success, the lock is destroyed; but
# if it exits with failure (non-zero), the unlock action is aborted
# and STDERR is returned to the client.
 
# On a Unix system, the normal procedure is to have 'pre-unlock'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'pre-unlock' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'pre-unlock.bat' or 'pre-unlock.exe',
# but the basic idea is the same.
#
# Here is an example hook script, for a Unix /bin/sh interpreter:
 
REPOS="$1"
PATH="$2"
USER="$3"
 
# If a lock is owned by a different person, don't allow it be broken.
# (Maybe this script could send email to the lock owner?)
 
SVNLOOK=/usr/bin/svnlook
GREP=/bin/grep
SED=/bin/sed
 
LOCK_OWNER=`$SVNLOOK lock "$REPOS" "$PATH" | \
$GREP '^Owner: ' | $SED 's/Owner: //'`
 
# If we get no result from svnlook, there's no lock, return success:
if [ "$LOCK_OWNER" = "" ]; then
exit 0
fi
 
# If the person unlocking matches the lock's owner, return success:
if [ "$LOCK_OWNER" = "$USER" ]; then
exit 0
fi
 
# Otherwise, we've got an owner mismatch, so return failure:
echo "Error: $PATH locked by ${LOCK_OWNER}." 1>&2
exit 1
/FollowMe/hooks/start-commit.tmpl
0,0 → 1,65
#!/bin/sh
 
# START-COMMIT HOOK
#
# The start-commit hook is invoked before a Subversion txn is created
# in the process of doing a commit. Subversion runs this hook
# by invoking a program (script, executable, binary, etc.) named
# 'start-commit' (for which this file is a template)
# with the following ordered arguments:
#
# [1] REPOS-PATH (the path to this repository)
# [2] USER (the authenticated user attempting to commit)
# [3] CAPABILITIES (a colon-separated list of capabilities reported
# by the client; see note below)
#
# Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5
# clients will typically report at least the "mergeinfo" capability.
# If there are other capabilities, then the list is colon-separated,
# e.g.: "mergeinfo:some-other-capability" (the order is undefined).
#
# The list is self-reported by the client. Therefore, you should not
# make security assumptions based on the capabilities list, nor should
# you assume that clients reliably report every capability they have.
#
# The working directory for this hook program's invocation is undefined,
# so the program should set one explicitly if it cares.
#
# If the hook program exits with success, the commit continues; but
# if it exits with failure (non-zero), the commit is stopped before
# a Subversion txn is created, and STDERR is returned to the client.
#
# On a Unix system, the normal procedure is to have 'start-commit'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'start-commit' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'start-commit.bat' or 'start-commit.exe',
# but the basic idea is the same.
#
# The hook program typically does not inherit the environment of
# its parent process. For example, a common problem is for the
# PATH environment variable to not be set to its usual value, so
# that subprograms fail to launch unless invoked via absolute path.
# If you're having unexpected problems with a hook program, the
# culprit may be unusual (or missing) environment variables.
#
# Here is an example hook script, for a Unix /bin/sh interpreter.
# For more examples and pre-written hooks, see those in
# the Subversion repository at
# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and
# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/
 
 
REPOS="$1"
USER="$2"
 
commit-allower.pl --repository "$REPOS" --user "$USER" || exit 1
special-auth-check.py --user "$USER" --auth-level 3 || exit 1
 
# All checks passed, so allow the commit.
exit 0
/FollowMe/locks/db-logs.lock
0,0 → 1,7
DB logs lock file, representing locks on the versioned filesystem logs.
 
All log manipulators of the repository's Berkeley DB environment
take out exclusive locks on this file to ensure that only one
accessor manipulates the logs at a time.
 
You should never have to edit or remove this file.
/FollowMe/locks/db.lock
0,0 → 1,10
DB lock file, representing locks on the versioned filesystem.
 
All accessors -- both readers and writers -- of the repository's
Berkeley DB environment take out shared locks on this file, and
each accessor removes its lock when done. If and when the DB
recovery procedure is run, the recovery code takes out an
exclusive lock on this file, so we can be sure no one else is
using the DB during the recovery.
 
You should never have to edit or remove this file.