WB 2.08.x

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.

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 manupulates the logs at the time.

You should never have to edit or remove this file.

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.

If 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.

#!/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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/

REPOS="$1"

REV="$2"

commit-email.pl "$REPOS" "$REV" commit-watchers@example.org

log-commit.py --repository "$REPOS" --revision "$REV"

#!/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)

#

# 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 to the lock owner?)

SVNLOOK=/usr/local/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

#!/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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/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

#!/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)

#

# 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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/

REPOS="$1"

TXN="$2"

# Make sure that the log message contains some text.

SVNLOOK=/usr/local/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

#!/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)

#

# 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 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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/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

#!/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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/

REPOS="$1"

REV="$2"

USER="$3"

PROPNAME="$4"

ACTION="$5"

propchange-email.pl "$REPOS" "$REV" "$USER" "$PROPNAME" watchers@example.org

#!/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 locked paths at once in Subversion 1.3 and

# later).

#

# 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

#!/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 in Subversion 1.3 and

# later).

#

# 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

#!/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)

#

# 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 broken.

# (Maybe this script could send email to the to the lock owner?)

SVNLOOK=/usr/local/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

3

0 1 1

1

K 8

svn:date

V 27

2005-09-05T19:14:53.531250Z

END

ecb151cf-9b94-3649-ba58-e13799703548

fsfs

PLAIN

END

ENDREP

id: 0.0.r0/17

type: dir

count: 0

text: 0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e

cpath: /

17 107

### 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

### 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 conf directory.

### Uncomment the line below to use the default password file.

# password-db = passwd

### 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

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.

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 manupulates the logs at the time.

You should never have to edit or remove this file.

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.

If 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.

#!/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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/

REPOS="$1"

REV="$2"

commit-email.pl "$REPOS" "$REV" commit-watchers@example.org

log-commit.py --repository "$REPOS" --revision "$REV"

#!/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)

#

# 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 to the lock owner?)

SVNLOOK=/usr/local/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

#!/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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/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

#!/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)

#

# 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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/

REPOS="$1"

TXN="$2"

# Make sure that the log message contains some text.

SVNLOOK=/usr/local/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

#!/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)

#

# 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 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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/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

#!/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.collab.net/repos/svn/trunk/tools/hook-scripts/ and

# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/

REPOS="$1"

REV="$2"

USER="$3"

PROPNAME="$4"

ACTION="$5"

propchange-email.pl "$REPOS" "$REV" "$USER" "$PROPNAME" watchers@example.org

#!/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 locked paths at once in Subversion 1.3 and

# later).

#

# 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

#!/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 in Subversion 1.3 and

# later).

#

# 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

#!/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)

#

# 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 broken.

# (Maybe this script could send email to the to the lock owner?)

SVNLOOK=/usr/local/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

3

0 1 1

1

K 8

svn:date

V 27

2005-09-05T19:19:23.203125Z

END

6b03b328-9bc6-3d48-be0f-2860eb8a9d3d

fsfs

PLAIN

END

ENDREP

id: 0.0.r0/17

type: dir

count: 0

text: 0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e

cpath: /

17 107

### 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

### 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 conf directory.

### Uncomment the line below to use the default password file.

# password-db = passwd

### 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

$MESSAGE['GROUPS']['GROUP_NAME_EXISTS'] = 'Group name already exists';

$results = $database->query("SELECT * FROM ".TABLE_PREFIX."groups WHERE name = '$group_name'");

if($results->numRows()>0) {

	$admin->print_error($MESSAGE['GROUPS']['GROUP_NAME_EXISTS'], $js_back);

}