WB 2.08.x

#!/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] REV          (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

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

#   [3] TXN-NAME     (the name of the transaction that has become REV)

#

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

TXN_NAME="$3"

mailer.py commit "$REPOS" "$REV" /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, 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

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

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

COMMENT="$4"

STEAL="$5"

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

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

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

TOKEN="$4"

BREAK="$5"

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

# 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

#!/bin/sh

# START-COMMIT HOOK

#

# The start-commit hook is invoked immediately after a Subversion txn is

# created and populated with initial revprops 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)

#   [4] TXN-NAME     (the name of the commit txn just created)

#

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

#

# Note: The TXN-NAME parameter is new in Subversion 1.8.  Prior to version

# 1.8, the start-commit hook was invoked before the commit txn was even

# created, so the ability to inspect the commit txn and its metadata from

# within the start-commit hook was not possible.

# 

# 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

### 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.apache.org/ for more information.

[general]

### The anon-access and auth-access options control access to the

### repository for unauthenticated (a.k.a. anonymous) users and

### authenticated users, respectively.

### Valid values are "write", "read", and "none".

### Setting the value to "none" prohibits both reading and writing;

### "read" allows read-only access, and "write" allows complete 

### read/write access to the repository.

### The sample settings below are the defaults and specify that anonymous

### users have read-only access to the repository, while authenticated

### users have read and write access to the repository.

# 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

### directory containing this file.  The specified path may be a

### repository relative URL (^/) or an absolute file:// URL to a text

### file in a Subversion repository.  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

### The groups-db option controls the location of the groups file.

### Unless you specify a path starting with a /, the file's location is

### relative to the directory containing this file.  The specified path

### may be a repository relative URL (^/) or an absolute file:// URL to a

### text file in a Subversion repository.

# groups-db = groups

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

### The force-username-case option causes svnserve to case-normalize

### usernames before comparing them against the authorization rules in the

### authz-db file configured above.  Valid values are "upper" (to upper-

### case the usernames), "lower" (to lowercase the usernames), and

### "none" (to compare usernames as-is without case conversion, which

### is the default behavior).

# force-username-case = none

### The hooks-env options specifies a path to the hook script environment 

### configuration file. This option overrides the per-repository default

### and can be used to configure the hook script environment for multiple 

### repositories in a single file, if an absolute path is specified.

### Unless you specify an absolute path, the file's location is relative

### to the directory containing this file.

# hooks-env = hooks-env

[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

### 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 is an example hook script environment configuration file.

### Hook scripts run in an empty environment by default.

### As shown below each section defines environment variables for a

### particular hook script. The [default] section defines environment

### variables for all hook scripts, unless overridden by a hook-specific

### section.

### This example configures a UTF-8 locale for all hook scripts, so that 

### special characters, such as umlauts, may be printed to stderr.

### If UTF-8 is used with a mod_dav_svn server, the SVNUseUTF8 option must

### also be set to 'yes' in httpd.conf.

### With svnserve, the LANG environment variable of the svnserve process

### must be set to the same value as given here.

[default]

LANG = en_US.UTF-8

### This sets the PATH environment variable for the pre-commit hook.

[pre-commit]

PATH = /usr/local/bin:/usr/bin:/usr/sbin

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

PLAIN

END

ENDREP

id: 0.0.r0/17

type: dir

count: 0

text: 0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e

cpath: /

17 107

id: 0-1.0.r1/0

type: dir

count: 0

cpath: /branches

copyroot: 0 /

id: 2-1.0.r1/66

type: dir

count: 0

cpath: /tags

copyroot: 0 /

id: 3-1.0.r1/129

type: dir

count: 0

cpath: /trunk

copyroot: 0 /

PLAIN

K 8

branches

V 14

dir 0-1.0.r1/0

K 4

tags

V 15

dir 2-1.0.r1/66

K 5

trunk

V 16

dir 3-1.0.r1/129

END

ENDREP

id: 0.0.r1/306

type: dir

pred: 0.0.r0/17

count: 1

text: 1 194 99 0 7df06f8ed258a32493a56932fb6da402

cpath: /

copyroot: 0 /

_0.0.t0-0 add-dir false false /branches

_2.0.t0-0 add-dir false false /tags

_3.0.t0-0 add-dir false false /trunk

306 430

K 8

svn:date

V 27

2014-09-22T16:37:46.471824Z

END

K 10

svn:author

V 10

Luisehahne

K 8

svn:date

V 27

2014-09-22T16:37:49.721045Z

K 7

svn:log

V 26

Importierte Ordnerstruktur

END

1

### This file controls the configuration of the FSFS filesystem.

[memcached-servers]

### These options name memcached servers used to cache internal FSFS

### data.  See http://www.danga.com/memcached/ for more information on

### memcached.  To use memcached with FSFS, run one or more memcached

### servers, and specify each of them as an option like so:

# first-server = 127.0.0.1:11211

# remote-memcached = mymemcached.corp.example.com:11212

### The option name is ignored; the value is of the form HOST:PORT.

### memcached servers can be shared between multiple repositories;

### however, if you do this, you *must* ensure that repositories have

### distinct UUIDs and paths, or else cached data from one repository

### might be used by another accidentally.  Note also that memcached has

### no authentication for reads or writes, so you must ensure that your

### memcached servers are only accessible by trusted users.

[caches]

### When a cache-related error occurs, normally Subversion ignores it

### and continues, logging an error if the server is appropriately

### configured (and ignoring it with file:// access).  To make

### Subversion never ignore cache errors, uncomment this line.

# fail-stop = true

[rep-sharing]

### To conserve space, the filesystem can optionally avoid storing

### duplicate representations.  This comes at a slight cost in

### performance, as maintaining a database of shared representations can

### increase commit times.  The space savings are dependent upon the size

### of the repository, the number of objects it contains and the amount of

### duplication between them, usually a function of the branching and

### merging process.

###

### The following parameter enables rep-sharing in the repository.  It can

### be switched on and off at will, but for best space-saving results

### should be enabled consistently over the life of the repository.

### 'svnadmin verify' will check the rep-cache regardless of this setting.

### rep-sharing is enabled by default.

# enable-rep-sharing = true

[deltification]

### To conserve space, the filesystem stores data as differences against

### existing representations.  This comes at a slight cost in performance,

### as calculating differences can increase commit times.  Reading data

### will also create higher CPU load and the data will be fragmented.

### Since deltification tends to save significant amounts of disk space,

### the overall I/O load can actually be lower.

###

### The options in this section allow for tuning the deltification

### strategy.  Their effects on data size and server performance may vary

### from one repository to another.  Versions prior to 1.8 will ignore

### this section.

###

### The following parameter enables deltification for directories. It can

### be switched on and off at will, but for best space-saving results

### should be enabled consistently over the life of the repository.

### Repositories containing large directories will benefit greatly.

### In rarely read repositories, the I/O overhead may be significant as

### cache hit rates will most likely be low

### directory deltification is disabled by default.

# enable-dir-deltification = false

###

### The following parameter enables deltification for properties on files

### and directories.  Overall, this is a minor tuning option but can save

### some disk space if you merge frequently or frequently change node

### properties.  You should not activate this if rep-sharing has been

### disabled because this may result in a net increase in repository size.

### property deltification is disabled by default.

# enable-props-deltification = false

###

### During commit, the server may need to walk the whole change history of

### of a given node to find a suitable deltification base.  This linear

### process can impact commit times, svnadmin load and similar operations.

### This setting limits the depth of the deltification history.  If the

### threshold has been reached, the node will be stored as fulltext and a

### new deltification history begins.

### Note, this is unrelated to svn log.

### Very large values rarely provide significant additional savings but

### can impact performance greatly - in particular if directory

### deltification has been activated.  Very small values may be useful in

### repositories that are dominated by large, changing binaries.

### Should be a power of two minus 1.  A value of 0 will effectively

### disable deltification.

### For 1.8, the default value is 1023; earlier versions have no limit.

# max-deltification-walk = 1023

###

### The skip-delta scheme used by FSFS tends to repeatably store redundant

### delta information where a simple delta against the latest version is

### often smaller.  By default, 1.8+ will therefore use skip deltas only

### after the linear chain of deltas has grown beyond the threshold

### specified by this setting.

### Values up to 64 can result in some reduction in repository size for

### the cost of quickly increasing I/O and CPU costs. Similarly, smaller

### numbers can reduce those costs at the cost of more disk space.  For

### rarely read repositories or those containing larger binaries, this may

### present a better trade-off.

### Should be a power of two.  A value of 1 or smaller will cause the

### exclusive use of skip-deltas (as in pre-1.8).

### For 1.8, the default value is 16; earlier versions use 1.

# max-linear-deltification = 16

[packed-revprops]

### This parameter controls the size (in kBytes) of packed revprop files.

### Revprops of consecutive revisions will be concatenated into a single

### file up to but not exceeding the threshold given here.  However, each

### pack file may be much smaller and revprops of a single revision may be

### much larger than the limit set here.  The threshold will be applied

### before optional compression takes place.

### Large values will reduce disk space usage at the expense of increased

### latency and CPU usage reading and changing individual revprops.  They

### become an advantage when revprop caching has been enabled because a

### lot of data can be read in one go.  Values smaller than 4 kByte will

### not improve latency any further and quickly render revprop packing

### ineffective.

### revprop-pack-size is 64 kBytes by default for non-compressed revprop

### pack files and 256 kBytes when compression has been enabled.

# revprop-pack-size = 64

###

### To save disk space, packed revprop files may be compressed.  Standard

### revprops tend to allow for very effective compression.  Reading and

### even more so writing, become significantly more CPU intensive.  With

### revprop caching enabled, the overhead can be offset by reduced I/O

### unless you often modify revprops after packing.

### Compressing packed revprops is disabled by default.

# compress-packed-revprops = false

0

fd170441-563a-2142-b48a-317d2c796065

fsfs

6

layout sharded 1000

1

5

This is a Subversion repository; use the 'svnadmin' and 'svnlook' 

tools to examine it.  Do not add, delete, or modify files here 

unless you know how to avoid corrupting the repository.

Visit http://subversion.apache.org/ for more information.

This file is not used by Subversion 1.3.x or later.

However, its existence is required for compatibility with

Subversion 1.2.x or earlier.

This file is not used by Subversion 1.3.x or later.

However, its existence is required for compatibility with

Subversion 1.2.x or earlier.