Commit 447f7435422c447e2ee082560379cb40f502cd4a
1 parent
31081aa7
--no commit message
Showing
30 changed files
with
845 additions
and
0 deletions
Desktop.ini
0 → 100644
No preview for this file type
README.txt
0 → 100644
conf/authz
0 → 100644
| 1 | +### This file is an example authorization file for svnserve. | ||
| 2 | +### Its format is identical to that of mod_authz_svn authorization | ||
| 3 | +### files. | ||
| 4 | +### As shown below each section defines authorizations for the path and | ||
| 5 | +### (optional) repository specified by the section name. | ||
| 6 | +### The authorizations follow. An authorization line can refer to: | ||
| 7 | +### - a single user, | ||
| 8 | +### - a group of users defined in a special [groups] section, | ||
| 9 | +### - an alias defined in a special [aliases] section, | ||
| 10 | +### - all authenticated users, using the '$authenticated' token, | ||
| 11 | +### - only anonymous users, using the '$anonymous' token, | ||
| 12 | +### - anyone, using the '*' wildcard. | ||
| 13 | +### | ||
| 14 | +### A match can be inverted by prefixing the rule with '~'. Rules can | ||
| 15 | +### grant read ('r') access, read-write ('rw') access, or no access | ||
| 16 | +### (''). | ||
| 17 | + | ||
| 18 | +[aliases] | ||
| 19 | +# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average | ||
| 20 | + | ||
| 21 | +[groups] | ||
| 22 | +# harry_and_sally = harry,sally | ||
| 23 | +# harry_sally_and_joe = harry,sally,&joe | ||
| 24 | + | ||
| 25 | +# [/foo/bar] | ||
| 26 | +# harry = rw | ||
| 27 | +# &joe = r | ||
| 28 | +# * = | ||
| 29 | + | ||
| 30 | +# [repository:/baz/fuz] | ||
| 31 | +# @harry_and_sally = rw | ||
| 32 | +# * = r |
conf/hooks-env.tmpl
0 → 100644
| 1 | +### This file is an example hook script environment configuration file. | ||
| 2 | +### Hook scripts run in an empty environment by default. | ||
| 3 | +### As shown below each section defines environment variables for a | ||
| 4 | +### particular hook script. The [default] section defines environment | ||
| 5 | +### variables for all hook scripts, unless overridden by a hook-specific | ||
| 6 | +### section. | ||
| 7 | + | ||
| 8 | +### This example configures a UTF-8 locale for all hook scripts, so that | ||
| 9 | +### special characters, such as umlauts, may be printed to stderr. | ||
| 10 | +### If UTF-8 is used with a mod_dav_svn server, the SVNUseUTF8 option must | ||
| 11 | +### also be set to 'yes' in httpd.conf. | ||
| 12 | +### With svnserve, the LANG environment variable of the svnserve process | ||
| 13 | +### must be set to the same value as given here. | ||
| 14 | +[default] | ||
| 15 | +LANG = en_US.UTF-8 | ||
| 16 | + | ||
| 17 | +### This sets the PATH environment variable for the pre-commit hook. | ||
| 18 | +[pre-commit] | ||
| 19 | +PATH = /usr/local/bin:/usr/bin:/usr/sbin |
conf/passwd
0 → 100644
| 1 | +### This file is an example password file for svnserve. | ||
| 2 | +### Its format is similar to that of svnserve.conf. As shown in the | ||
| 3 | +### example below it contains one section labelled [users]. | ||
| 4 | +### The name and password for each user follow, one account per line. | ||
| 5 | + | ||
| 6 | +[users] | ||
| 7 | +# harry = harryssecret | ||
| 8 | +# sally = sallyssecret |
conf/svnserve.conf
0 → 100644
| 1 | +### This file controls the configuration of the svnserve daemon, if you | ||
| 2 | +### use it to allow access to this repository. (If you only allow | ||
| 3 | +### access through http: and/or file: URLs, then this file is | ||
| 4 | +### irrelevant.) | ||
| 5 | + | ||
| 6 | +### Visit http://subversion.apache.org/ for more information. | ||
| 7 | + | ||
| 8 | +[general] | ||
| 9 | +### The anon-access and auth-access options control access to the | ||
| 10 | +### repository for unauthenticated (a.k.a. anonymous) users and | ||
| 11 | +### authenticated users, respectively. | ||
| 12 | +### Valid values are "write", "read", and "none". | ||
| 13 | +### Setting the value to "none" prohibits both reading and writing; | ||
| 14 | +### "read" allows read-only access, and "write" allows complete | ||
| 15 | +### read/write access to the repository. | ||
| 16 | +### The sample settings below are the defaults and specify that anonymous | ||
| 17 | +### users have read-only access to the repository, while authenticated | ||
| 18 | +### users have read and write access to the repository. | ||
| 19 | +# anon-access = read | ||
| 20 | +# auth-access = write | ||
| 21 | +### The password-db option controls the location of the password | ||
| 22 | +### database file. Unless you specify a path starting with a /, | ||
| 23 | +### the file's location is relative to the directory containing | ||
| 24 | +### this configuration file. | ||
| 25 | +### If SASL is enabled (see below), this file will NOT be used. | ||
| 26 | +### Uncomment the line below to use the default password file. | ||
| 27 | +# password-db = passwd | ||
| 28 | +### The authz-db option controls the location of the authorization | ||
| 29 | +### rules for path-based access control. Unless you specify a path | ||
| 30 | +### starting with a /, the file's location is relative to the | ||
| 31 | +### directory containing this file. The specified path may be a | ||
| 32 | +### repository relative URL (^/) or an absolute file:// URL to a text | ||
| 33 | +### file in a Subversion repository. If you don't specify an authz-db, | ||
| 34 | +### no path-based access control is done. | ||
| 35 | +### Uncomment the line below to use the default authorization file. | ||
| 36 | +# authz-db = authz | ||
| 37 | +### The groups-db option controls the location of the groups file. | ||
| 38 | +### Unless you specify a path starting with a /, the file's location is | ||
| 39 | +### relative to the directory containing this file. The specified path | ||
| 40 | +### may be a repository relative URL (^/) or an absolute file:// URL to a | ||
| 41 | +### text file in a Subversion repository. | ||
| 42 | +# groups-db = groups | ||
| 43 | +### This option specifies the authentication realm of the repository. | ||
| 44 | +### If two repositories have the same authentication realm, they should | ||
| 45 | +### have the same password database, and vice versa. The default realm | ||
| 46 | +### is repository's uuid. | ||
| 47 | +# realm = My First Repository | ||
| 48 | +### The force-username-case option causes svnserve to case-normalize | ||
| 49 | +### usernames before comparing them against the authorization rules in the | ||
| 50 | +### authz-db file configured above. Valid values are "upper" (to upper- | ||
| 51 | +### case the usernames), "lower" (to lowercase the usernames), and | ||
| 52 | +### "none" (to compare usernames as-is without case conversion, which | ||
| 53 | +### is the default behavior). | ||
| 54 | +# force-username-case = none | ||
| 55 | +### The hooks-env options specifies a path to the hook script environment | ||
| 56 | +### configuration file. This option overrides the per-repository default | ||
| 57 | +### and can be used to configure the hook script environment for multiple | ||
| 58 | +### repositories in a single file, if an absolute path is specified. | ||
| 59 | +### Unless you specify an absolute path, the file's location is relative | ||
| 60 | +### to the directory containing this file. | ||
| 61 | +# hooks-env = hooks-env | ||
| 62 | + | ||
| 63 | +[sasl] | ||
| 64 | +### This option specifies whether you want to use the Cyrus SASL | ||
| 65 | +### library for authentication. Default is false. | ||
| 66 | +### This section will be ignored if svnserve is not built with Cyrus | ||
| 67 | +### SASL support; to check, run 'svnserve --version' and look for a line | ||
| 68 | +### reading 'Cyrus SASL authentication is available.' | ||
| 69 | +# use-sasl = true | ||
| 70 | +### These options specify the desired strength of the security layer | ||
| 71 | +### that you want SASL to provide. 0 means no encryption, 1 means | ||
| 72 | +### integrity-checking only, values larger than 1 are correlated | ||
| 73 | +### to the effective key length for encryption (e.g. 128 means 128-bit | ||
| 74 | +### encryption). The values below are the defaults. | ||
| 75 | +# min-encryption = 0 | ||
| 76 | +# max-encryption = 256 |
db/current
0 → 100644
| 1 | +0 |
db/format
0 → 100644
db/fs-type
0 → 100644
| 1 | +fsfs |
db/fsfs.conf
0 → 100644
| 1 | +### This file controls the configuration of the FSFS filesystem. | ||
| 2 | + | ||
| 3 | +[memcached-servers] | ||
| 4 | +### These options name memcached servers used to cache internal FSFS | ||
| 5 | +### data. See http://www.danga.com/memcached/ for more information on | ||
| 6 | +### memcached. To use memcached with FSFS, run one or more memcached | ||
| 7 | +### servers, and specify each of them as an option like so: | ||
| 8 | +# first-server = 127.0.0.1:11211 | ||
| 9 | +# remote-memcached = mymemcached.corp.example.com:11212 | ||
| 10 | +### The option name is ignored; the value is of the form HOST:PORT. | ||
| 11 | +### memcached servers can be shared between multiple repositories; | ||
| 12 | +### however, if you do this, you *must* ensure that repositories have | ||
| 13 | +### distinct UUIDs and paths, or else cached data from one repository | ||
| 14 | +### might be used by another accidentally. Note also that memcached has | ||
| 15 | +### no authentication for reads or writes, so you must ensure that your | ||
| 16 | +### memcached servers are only accessible by trusted users. | ||
| 17 | + | ||
| 18 | +[caches] | ||
| 19 | +### When a cache-related error occurs, normally Subversion ignores it | ||
| 20 | +### and continues, logging an error if the server is appropriately | ||
| 21 | +### configured (and ignoring it with file:// access). To make | ||
| 22 | +### Subversion never ignore cache errors, uncomment this line. | ||
| 23 | +# fail-stop = true | ||
| 24 | + | ||
| 25 | +[rep-sharing] | ||
| 26 | +### To conserve space, the filesystem can optionally avoid storing | ||
| 27 | +### duplicate representations. This comes at a slight cost in | ||
| 28 | +### performance, as maintaining a database of shared representations can | ||
| 29 | +### increase commit times. The space savings are dependent upon the size | ||
| 30 | +### of the repository, the number of objects it contains and the amount of | ||
| 31 | +### duplication between them, usually a function of the branching and | ||
| 32 | +### merging process. | ||
| 33 | +### | ||
| 34 | +### The following parameter enables rep-sharing in the repository. It can | ||
| 35 | +### be switched on and off at will, but for best space-saving results | ||
| 36 | +### should be enabled consistently over the life of the repository. | ||
| 37 | +### 'svnadmin verify' will check the rep-cache regardless of this setting. | ||
| 38 | +### rep-sharing is enabled by default. | ||
| 39 | +# enable-rep-sharing = true | ||
| 40 | + | ||
| 41 | +[deltification] | ||
| 42 | +### To conserve space, the filesystem stores data as differences against | ||
| 43 | +### existing representations. This comes at a slight cost in performance, | ||
| 44 | +### as calculating differences can increase commit times. Reading data | ||
| 45 | +### will also create higher CPU load and the data will be fragmented. | ||
| 46 | +### Since deltification tends to save significant amounts of disk space, | ||
| 47 | +### the overall I/O load can actually be lower. | ||
| 48 | +### | ||
| 49 | +### The options in this section allow for tuning the deltification | ||
| 50 | +### strategy. Their effects on data size and server performance may vary | ||
| 51 | +### from one repository to another. Versions prior to 1.8 will ignore | ||
| 52 | +### this section. | ||
| 53 | +### | ||
| 54 | +### The following parameter enables deltification for directories. It can | ||
| 55 | +### be switched on and off at will, but for best space-saving results | ||
| 56 | +### should be enabled consistently over the life of the repository. | ||
| 57 | +### Repositories containing large directories will benefit greatly. | ||
| 58 | +### In rarely read repositories, the I/O overhead may be significant as | ||
| 59 | +### cache hit rates will most likely be low | ||
| 60 | +### directory deltification is disabled by default. | ||
| 61 | +# enable-dir-deltification = false | ||
| 62 | +### | ||
| 63 | +### The following parameter enables deltification for properties on files | ||
| 64 | +### and directories. Overall, this is a minor tuning option but can save | ||
| 65 | +### some disk space if you merge frequently or frequently change node | ||
| 66 | +### properties. You should not activate this if rep-sharing has been | ||
| 67 | +### disabled because this may result in a net increase in repository size. | ||
| 68 | +### property deltification is disabled by default. | ||
| 69 | +# enable-props-deltification = false | ||
| 70 | +### | ||
| 71 | +### During commit, the server may need to walk the whole change history of | ||
| 72 | +### of a given node to find a suitable deltification base. This linear | ||
| 73 | +### process can impact commit times, svnadmin load and similar operations. | ||
| 74 | +### This setting limits the depth of the deltification history. If the | ||
| 75 | +### threshold has been reached, the node will be stored as fulltext and a | ||
| 76 | +### new deltification history begins. | ||
| 77 | +### Note, this is unrelated to svn log. | ||
| 78 | +### Very large values rarely provide significant additional savings but | ||
| 79 | +### can impact performance greatly - in particular if directory | ||
| 80 | +### deltification has been activated. Very small values may be useful in | ||
| 81 | +### repositories that are dominated by large, changing binaries. | ||
| 82 | +### Should be a power of two minus 1. A value of 0 will effectively | ||
| 83 | +### disable deltification. | ||
| 84 | +### For 1.8, the default value is 1023; earlier versions have no limit. | ||
| 85 | +# max-deltification-walk = 1023 | ||
| 86 | +### | ||
| 87 | +### The skip-delta scheme used by FSFS tends to repeatably store redundant | ||
| 88 | +### delta information where a simple delta against the latest version is | ||
| 89 | +### often smaller. By default, 1.8+ will therefore use skip deltas only | ||
| 90 | +### after the linear chain of deltas has grown beyond the threshold | ||
| 91 | +### specified by this setting. | ||
| 92 | +### Values up to 64 can result in some reduction in repository size for | ||
| 93 | +### the cost of quickly increasing I/O and CPU costs. Similarly, smaller | ||
| 94 | +### numbers can reduce those costs at the cost of more disk space. For | ||
| 95 | +### rarely read repositories or those containing larger binaries, this may | ||
| 96 | +### present a better trade-off. | ||
| 97 | +### Should be a power of two. A value of 1 or smaller will cause the | ||
| 98 | +### exclusive use of skip-deltas (as in pre-1.8). | ||
| 99 | +### For 1.8, the default value is 16; earlier versions use 1. | ||
| 100 | +# max-linear-deltification = 16 | ||
| 101 | + | ||
| 102 | +[packed-revprops] | ||
| 103 | +### This parameter controls the size (in kBytes) of packed revprop files. | ||
| 104 | +### Revprops of consecutive revisions will be concatenated into a single | ||
| 105 | +### file up to but not exceeding the threshold given here. However, each | ||
| 106 | +### pack file may be much smaller and revprops of a single revision may be | ||
| 107 | +### much larger than the limit set here. The threshold will be applied | ||
| 108 | +### before optional compression takes place. | ||
| 109 | +### Large values will reduce disk space usage at the expense of increased | ||
| 110 | +### latency and CPU usage reading and changing individual revprops. They | ||
| 111 | +### become an advantage when revprop caching has been enabled because a | ||
| 112 | +### lot of data can be read in one go. Values smaller than 4 kByte will | ||
| 113 | +### not improve latency any further and quickly render revprop packing | ||
| 114 | +### ineffective. | ||
| 115 | +### revprop-pack-size is 64 kBytes by default for non-compressed revprop | ||
| 116 | +### pack files and 256 kBytes when compression has been enabled. | ||
| 117 | +# revprop-pack-size = 64 | ||
| 118 | +### | ||
| 119 | +### To save disk space, packed revprop files may be compressed. Standard | ||
| 120 | +### revprops tend to allow for very effective compression. Reading and | ||
| 121 | +### even more so writing, become significantly more CPU intensive. With | ||
| 122 | +### revprop caching enabled, the overhead can be offset by reduced I/O | ||
| 123 | +### unless you often modify revprops after packing. | ||
| 124 | +### Compressing packed revprops is disabled by default. | ||
| 125 | +# compress-packed-revprops = false |
db/min-unpacked-rev
0 → 100644
| 1 | +0 |
db/revprops/0/0
0 → 100644
db/revs/0/0
0 → 100644
db/txn-current
0 → 100644
| 1 | +0 |
db/txn-current-lock
0 → 100644
db/uuid
0 → 100644
| 1 | +021b3fa0-809a-1b44-becf-4448bca289f5 |
db/write-lock
0 → 100644
format
0 → 100644
| 1 | +5 |
hooks/post-commit.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# POST-COMMIT HOOK | ||
| 4 | +# | ||
| 5 | +# The post-commit hook is invoked after a commit. Subversion runs | ||
| 6 | +# this hook by invoking a program (script, executable, binary, etc.) | ||
| 7 | +# named 'post-commit' (for which this file is a template) with the | ||
| 8 | +# following ordered arguments: | ||
| 9 | +# | ||
| 10 | +# [1] REPOS-PATH (the path to this repository) | ||
| 11 | +# [2] REV (the number of the revision just committed) | ||
| 12 | +# [3] TXN-NAME (the name of the transaction that has become REV) | ||
| 13 | +# | ||
| 14 | +# The default working directory for the invocation is undefined, so | ||
| 15 | +# the program should set one explicitly if it cares. | ||
| 16 | +# | ||
| 17 | +# Because the commit has already completed and cannot be undone, | ||
| 18 | +# the exit code of the hook program is ignored. The hook program | ||
| 19 | +# can use the 'svnlook' utility to help it examine the | ||
| 20 | +# newly-committed tree. | ||
| 21 | +# | ||
| 22 | +# On a Unix system, the normal procedure is to have 'post-commit' | ||
| 23 | +# invoke other programs to do the real work, though it may do the | ||
| 24 | +# work itself too. | ||
| 25 | +# | ||
| 26 | +# Note that 'post-commit' must be executable by the user(s) who will | ||
| 27 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 28 | +# have filesystem-level permission to access the repository. | ||
| 29 | +# | ||
| 30 | +# On a Windows system, you should name the hook program | ||
| 31 | +# 'post-commit.bat' or 'post-commit.exe', | ||
| 32 | +# but the basic idea is the same. | ||
| 33 | +# | ||
| 34 | +# The hook program typically does not inherit the environment of | ||
| 35 | +# its parent process. For example, a common problem is for the | ||
| 36 | +# PATH environment variable to not be set to its usual value, so | ||
| 37 | +# that subprograms fail to launch unless invoked via absolute path. | ||
| 38 | +# If you're having unexpected problems with a hook program, the | ||
| 39 | +# culprit may be unusual (or missing) environment variables. | ||
| 40 | +# | ||
| 41 | +# Here is an example hook script, for a Unix /bin/sh interpreter. | ||
| 42 | +# For more examples and pre-written hooks, see those in | ||
| 43 | +# the Subversion repository at | ||
| 44 | +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and | ||
| 45 | +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ | ||
| 46 | + | ||
| 47 | + | ||
| 48 | +REPOS="$1" | ||
| 49 | +REV="$2" | ||
| 50 | +TXN_NAME="$3" | ||
| 51 | + | ||
| 52 | +mailer.py commit "$REPOS" "$REV" /path/to/mailer.conf |
hooks/post-lock.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# POST-LOCK HOOK | ||
| 4 | +# | ||
| 5 | +# The post-lock hook is run after a path is locked. Subversion runs | ||
| 6 | +# this hook by invoking a program (script, executable, binary, etc.) | ||
| 7 | +# named 'post-lock' (for which this file is a template) with the | ||
| 8 | +# following ordered arguments: | ||
| 9 | +# | ||
| 10 | +# [1] REPOS-PATH (the path to this repository) | ||
| 11 | +# [2] USER (the user who created the lock) | ||
| 12 | +# | ||
| 13 | +# The paths that were just locked are passed to the hook via STDIN (as | ||
| 14 | +# of Subversion 1.2, only one path is passed per invocation, but the | ||
| 15 | +# plan is to pass all locked paths at once, so the hook program | ||
| 16 | +# should be written accordingly). | ||
| 17 | +# | ||
| 18 | +# The default working directory for the invocation is undefined, so | ||
| 19 | +# the program should set one explicitly if it cares. | ||
| 20 | +# | ||
| 21 | +# Because the lock has already been created and cannot be undone, | ||
| 22 | +# the exit code of the hook program is ignored. The hook program | ||
| 23 | +# can use the 'svnlook' utility to help it examine the | ||
| 24 | +# newly-created lock. | ||
| 25 | +# | ||
| 26 | +# On a Unix system, the normal procedure is to have 'post-lock' | ||
| 27 | +# invoke other programs to do the real work, though it may do the | ||
| 28 | +# work itself too. | ||
| 29 | +# | ||
| 30 | +# Note that 'post-lock' must be executable by the user(s) who will | ||
| 31 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 32 | +# have filesystem-level permission to access the repository. | ||
| 33 | +# | ||
| 34 | +# On a Windows system, you should name the hook program | ||
| 35 | +# 'post-lock.bat' or 'post-lock.exe', | ||
| 36 | +# but the basic idea is the same. | ||
| 37 | +# | ||
| 38 | +# Here is an example hook script, for a Unix /bin/sh interpreter: | ||
| 39 | + | ||
| 40 | +REPOS="$1" | ||
| 41 | +USER="$2" | ||
| 42 | + | ||
| 43 | +# Send email to interested parties, let them know a lock was created: | ||
| 44 | +mailer.py lock "$REPOS" "$USER" /path/to/mailer.conf |
hooks/post-revprop-change.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# POST-REVPROP-CHANGE HOOK | ||
| 4 | +# | ||
| 5 | +# The post-revprop-change hook is invoked after a revision property | ||
| 6 | +# has been added, modified or deleted. Subversion runs this hook by | ||
| 7 | +# invoking a program (script, executable, binary, etc.) named | ||
| 8 | +# 'post-revprop-change' (for which this file is a template), with the | ||
| 9 | +# following ordered arguments: | ||
| 10 | +# | ||
| 11 | +# [1] REPOS-PATH (the path to this repository) | ||
| 12 | +# [2] REV (the revision that was tweaked) | ||
| 13 | +# [3] USER (the username of the person tweaking the property) | ||
| 14 | +# [4] PROPNAME (the property that was changed) | ||
| 15 | +# [5] ACTION (the property was 'A'dded, 'M'odified, or 'D'eleted) | ||
| 16 | +# | ||
| 17 | +# [STDIN] PROPVAL ** the old property value is passed via STDIN. | ||
| 18 | +# | ||
| 19 | +# Because the propchange has already completed and cannot be undone, | ||
| 20 | +# the exit code of the hook program is ignored. The hook program | ||
| 21 | +# can use the 'svnlook' utility to help it examine the | ||
| 22 | +# new property value. | ||
| 23 | +# | ||
| 24 | +# On a Unix system, the normal procedure is to have 'post-revprop-change' | ||
| 25 | +# invoke other programs to do the real work, though it may do the | ||
| 26 | +# work itself too. | ||
| 27 | +# | ||
| 28 | +# Note that 'post-revprop-change' must be executable by the user(s) who will | ||
| 29 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 30 | +# have filesystem-level permission to access the repository. | ||
| 31 | +# | ||
| 32 | +# On a Windows system, you should name the hook program | ||
| 33 | +# 'post-revprop-change.bat' or 'post-revprop-change.exe', | ||
| 34 | +# but the basic idea is the same. | ||
| 35 | +# | ||
| 36 | +# The hook program typically does not inherit the environment of | ||
| 37 | +# its parent process. For example, a common problem is for the | ||
| 38 | +# PATH environment variable to not be set to its usual value, so | ||
| 39 | +# that subprograms fail to launch unless invoked via absolute path. | ||
| 40 | +# If you're having unexpected problems with a hook program, the | ||
| 41 | +# culprit may be unusual (or missing) environment variables. | ||
| 42 | +# | ||
| 43 | +# Here is an example hook script, for a Unix /bin/sh interpreter. | ||
| 44 | +# For more examples and pre-written hooks, see those in | ||
| 45 | +# the Subversion repository at | ||
| 46 | +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and | ||
| 47 | +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ | ||
| 48 | + | ||
| 49 | + | ||
| 50 | +REPOS="$1" | ||
| 51 | +REV="$2" | ||
| 52 | +USER="$3" | ||
| 53 | +PROPNAME="$4" | ||
| 54 | +ACTION="$5" | ||
| 55 | + | ||
| 56 | +mailer.py propchange2 "$REPOS" "$REV" "$USER" "$PROPNAME" "$ACTION" /path/to/mailer.conf |
hooks/post-unlock.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# POST-UNLOCK HOOK | ||
| 4 | +# | ||
| 5 | +# The post-unlock hook runs after a path is unlocked. Subversion runs | ||
| 6 | +# this hook by invoking a program (script, executable, binary, etc.) | ||
| 7 | +# named 'post-unlock' (for which this file is a template) with the | ||
| 8 | +# following ordered arguments: | ||
| 9 | +# | ||
| 10 | +# [1] REPOS-PATH (the path to this repository) | ||
| 11 | +# [2] USER (the user who destroyed the lock) | ||
| 12 | +# | ||
| 13 | +# The paths that were just unlocked are passed to the hook via STDIN | ||
| 14 | +# (as of Subversion 1.2, only one path is passed per invocation, but | ||
| 15 | +# the plan is to pass all unlocked paths at once, so the hook program | ||
| 16 | +# should be written accordingly). | ||
| 17 | +# | ||
| 18 | +# The default working directory for the invocation is undefined, so | ||
| 19 | +# the program should set one explicitly if it cares. | ||
| 20 | +# | ||
| 21 | +# Because the lock has already been destroyed and cannot be undone, | ||
| 22 | +# the exit code of the hook program is ignored. | ||
| 23 | +# | ||
| 24 | +# On a Unix system, the normal procedure is to have 'post-unlock' | ||
| 25 | +# invoke other programs to do the real work, though it may do the | ||
| 26 | +# work itself too. | ||
| 27 | +# | ||
| 28 | +# Note that 'post-unlock' must be executable by the user(s) who will | ||
| 29 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 30 | +# have filesystem-level permission to access the repository. | ||
| 31 | +# | ||
| 32 | +# On a Windows system, you should name the hook program | ||
| 33 | +# 'post-unlock.bat' or 'post-unlock.exe', | ||
| 34 | +# but the basic idea is the same. | ||
| 35 | +# | ||
| 36 | +# Here is an example hook script, for a Unix /bin/sh interpreter: | ||
| 37 | + | ||
| 38 | +REPOS="$1" | ||
| 39 | +USER="$2" | ||
| 40 | + | ||
| 41 | +# Send email to interested parties, let them know a lock was removed: | ||
| 42 | +mailer.py unlock "$REPOS" "$USER" /path/to/mailer.conf |
hooks/pre-commit.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# PRE-COMMIT HOOK | ||
| 4 | +# | ||
| 5 | +# The pre-commit hook is invoked before a Subversion txn is | ||
| 6 | +# committed. Subversion runs this hook by invoking a program | ||
| 7 | +# (script, executable, binary, etc.) named 'pre-commit' (for which | ||
| 8 | +# this file is a template), with the following ordered arguments: | ||
| 9 | +# | ||
| 10 | +# [1] REPOS-PATH (the path to this repository) | ||
| 11 | +# [2] TXN-NAME (the name of the txn about to be committed) | ||
| 12 | +# | ||
| 13 | +# [STDIN] LOCK-TOKENS ** the lock tokens are passed via STDIN. | ||
| 14 | +# | ||
| 15 | +# If STDIN contains the line "LOCK-TOKENS:\n" (the "\n" denotes a | ||
| 16 | +# single newline), the lines following it are the lock tokens for | ||
| 17 | +# this commit. The end of the list is marked by a line containing | ||
| 18 | +# only a newline character. | ||
| 19 | +# | ||
| 20 | +# Each lock token line consists of a URI-escaped path, followed | ||
| 21 | +# by the separator character '|', followed by the lock token string, | ||
| 22 | +# followed by a newline. | ||
| 23 | +# | ||
| 24 | +# The default working directory for the invocation is undefined, so | ||
| 25 | +# the program should set one explicitly if it cares. | ||
| 26 | +# | ||
| 27 | +# If the hook program exits with success, the txn is committed; but | ||
| 28 | +# if it exits with failure (non-zero), the txn is aborted, no commit | ||
| 29 | +# takes place, and STDERR is returned to the client. The hook | ||
| 30 | +# program can use the 'svnlook' utility to help it examine the txn. | ||
| 31 | +# | ||
| 32 | +# On a Unix system, the normal procedure is to have 'pre-commit' | ||
| 33 | +# invoke other programs to do the real work, though it may do the | ||
| 34 | +# work itself too. | ||
| 35 | +# | ||
| 36 | +# *** NOTE: THE HOOK PROGRAM MUST NOT MODIFY THE TXN, EXCEPT *** | ||
| 37 | +# *** FOR REVISION PROPERTIES (like svn:log or svn:author). *** | ||
| 38 | +# | ||
| 39 | +# This is why we recommend using the read-only 'svnlook' utility. | ||
| 40 | +# In the future, Subversion may enforce the rule that pre-commit | ||
| 41 | +# hooks should not modify the versioned data in txns, or else come | ||
| 42 | +# up with a mechanism to make it safe to do so (by informing the | ||
| 43 | +# committing client of the changes). However, right now neither | ||
| 44 | +# mechanism is implemented, so hook writers just have to be careful. | ||
| 45 | +# | ||
| 46 | +# Note that 'pre-commit' must be executable by the user(s) who will | ||
| 47 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 48 | +# have filesystem-level permission to access the repository. | ||
| 49 | +# | ||
| 50 | +# On a Windows system, you should name the hook program | ||
| 51 | +# 'pre-commit.bat' or 'pre-commit.exe', | ||
| 52 | +# but the basic idea is the same. | ||
| 53 | +# | ||
| 54 | +# The hook program typically does not inherit the environment of | ||
| 55 | +# its parent process. For example, a common problem is for the | ||
| 56 | +# PATH environment variable to not be set to its usual value, so | ||
| 57 | +# that subprograms fail to launch unless invoked via absolute path. | ||
| 58 | +# If you're having unexpected problems with a hook program, the | ||
| 59 | +# culprit may be unusual (or missing) environment variables. | ||
| 60 | +# | ||
| 61 | +# Here is an example hook script, for a Unix /bin/sh interpreter. | ||
| 62 | +# For more examples and pre-written hooks, see those in | ||
| 63 | +# the Subversion repository at | ||
| 64 | +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and | ||
| 65 | +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ | ||
| 66 | + | ||
| 67 | + | ||
| 68 | +REPOS="$1" | ||
| 69 | +TXN="$2" | ||
| 70 | + | ||
| 71 | +# Make sure that the log message contains some text. | ||
| 72 | +SVNLOOK=/usr/local/bin/svnlook | ||
| 73 | +$SVNLOOK log -t "$TXN" "$REPOS" | \ | ||
| 74 | + grep "[a-zA-Z0-9]" > /dev/null || exit 1 | ||
| 75 | + | ||
| 76 | +# Check that the author of this commit has the rights to perform | ||
| 77 | +# the commit on the files and directories being modified. | ||
| 78 | +commit-access-control.pl "$REPOS" "$TXN" commit-access-control.cfg || exit 1 | ||
| 79 | + | ||
| 80 | +# All checks passed, so allow the commit. | ||
| 81 | +exit 0 |
hooks/pre-lock.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# PRE-LOCK HOOK | ||
| 4 | +# | ||
| 5 | +# The pre-lock hook is invoked before an exclusive lock is | ||
| 6 | +# created. Subversion runs this hook by invoking a program | ||
| 7 | +# (script, executable, binary, etc.) named 'pre-lock' (for which | ||
| 8 | +# this file is a template), with the following ordered arguments: | ||
| 9 | +# | ||
| 10 | +# [1] REPOS-PATH (the path to this repository) | ||
| 11 | +# [2] PATH (the path in the repository about to be locked) | ||
| 12 | +# [3] USER (the user creating the lock) | ||
| 13 | +# [4] COMMENT (the comment of the lock) | ||
| 14 | +# [5] STEAL-LOCK (1 if the user is trying to steal the lock, else 0) | ||
| 15 | +# | ||
| 16 | +# If the hook program outputs anything on stdout, the output string will | ||
| 17 | +# be used as the lock token for this lock operation. If you choose to use | ||
| 18 | +# this feature, you must guarantee the tokens generated are unique across | ||
| 19 | +# the repository each time. | ||
| 20 | +# | ||
| 21 | +# The default working directory for the invocation is undefined, so | ||
| 22 | +# the program should set one explicitly if it cares. | ||
| 23 | +# | ||
| 24 | +# If the hook program exits with success, the lock is created; but | ||
| 25 | +# if it exits with failure (non-zero), the lock action is aborted | ||
| 26 | +# and STDERR is returned to the client. | ||
| 27 | + | ||
| 28 | +# On a Unix system, the normal procedure is to have 'pre-lock' | ||
| 29 | +# invoke other programs to do the real work, though it may do the | ||
| 30 | +# work itself too. | ||
| 31 | +# | ||
| 32 | +# Note that 'pre-lock' must be executable by the user(s) who will | ||
| 33 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 34 | +# have filesystem-level permission to access the repository. | ||
| 35 | +# | ||
| 36 | +# On a Windows system, you should name the hook program | ||
| 37 | +# 'pre-lock.bat' or 'pre-lock.exe', | ||
| 38 | +# but the basic idea is the same. | ||
| 39 | +# | ||
| 40 | +# Here is an example hook script, for a Unix /bin/sh interpreter: | ||
| 41 | + | ||
| 42 | +REPOS="$1" | ||
| 43 | +PATH="$2" | ||
| 44 | +USER="$3" | ||
| 45 | +COMMENT="$4" | ||
| 46 | +STEAL="$5" | ||
| 47 | + | ||
| 48 | +# If a lock exists and is owned by a different person, don't allow it | ||
| 49 | +# to be stolen (e.g., with 'svn lock --force ...'). | ||
| 50 | + | ||
| 51 | +# (Maybe this script could send email to the lock owner?) | ||
| 52 | +SVNLOOK=/usr/local/bin/svnlook | ||
| 53 | +GREP=/bin/grep | ||
| 54 | +SED=/bin/sed | ||
| 55 | + | ||
| 56 | +LOCK_OWNER=`$SVNLOOK lock "$REPOS" "$PATH" | \ | ||
| 57 | + $GREP '^Owner: ' | $SED 's/Owner: //'` | ||
| 58 | + | ||
| 59 | +# If we get no result from svnlook, there's no lock, allow the lock to | ||
| 60 | +# happen: | ||
| 61 | +if [ "$LOCK_OWNER" = "" ]; then | ||
| 62 | + exit 0 | ||
| 63 | +fi | ||
| 64 | + | ||
| 65 | +# If the person locking matches the lock's owner, allow the lock to | ||
| 66 | +# happen: | ||
| 67 | +if [ "$LOCK_OWNER" = "$USER" ]; then | ||
| 68 | + exit 0 | ||
| 69 | +fi | ||
| 70 | + | ||
| 71 | +# Otherwise, we've got an owner mismatch, so return failure: | ||
| 72 | +echo "Error: $PATH already locked by ${LOCK_OWNER}." 1>&2 | ||
| 73 | +exit 1 |
hooks/pre-revprop-change.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# PRE-REVPROP-CHANGE HOOK | ||
| 4 | +# | ||
| 5 | +# The pre-revprop-change hook is invoked before a revision property | ||
| 6 | +# is added, modified or deleted. Subversion runs this hook by invoking | ||
| 7 | +# a program (script, executable, binary, etc.) named 'pre-revprop-change' | ||
| 8 | +# (for which this file is a template), with the following ordered | ||
| 9 | +# arguments: | ||
| 10 | +# | ||
| 11 | +# [1] REPOS-PATH (the path to this repository) | ||
| 12 | +# [2] REV (the revision being tweaked) | ||
| 13 | +# [3] USER (the username of the person tweaking the property) | ||
| 14 | +# [4] PROPNAME (the property being set on the revision) | ||
| 15 | +# [5] ACTION (the property is being 'A'dded, 'M'odified, or 'D'eleted) | ||
| 16 | +# | ||
| 17 | +# [STDIN] PROPVAL ** the new property value is passed via STDIN. | ||
| 18 | +# | ||
| 19 | +# If the hook program exits with success, the propchange happens; but | ||
| 20 | +# if it exits with failure (non-zero), the propchange doesn't happen. | ||
| 21 | +# The hook program can use the 'svnlook' utility to examine the | ||
| 22 | +# existing value of the revision property. | ||
| 23 | +# | ||
| 24 | +# WARNING: unlike other hooks, this hook MUST exist for revision | ||
| 25 | +# properties to be changed. If the hook does not exist, Subversion | ||
| 26 | +# will behave as if the hook were present, but failed. The reason | ||
| 27 | +# for this is that revision properties are UNVERSIONED, meaning that | ||
| 28 | +# a successful propchange is destructive; the old value is gone | ||
| 29 | +# forever. We recommend the hook back up the old value somewhere. | ||
| 30 | +# | ||
| 31 | +# On a Unix system, the normal procedure is to have 'pre-revprop-change' | ||
| 32 | +# invoke other programs to do the real work, though it may do the | ||
| 33 | +# work itself too. | ||
| 34 | +# | ||
| 35 | +# Note that 'pre-revprop-change' must be executable by the user(s) who will | ||
| 36 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 37 | +# have filesystem-level permission to access the repository. | ||
| 38 | +# | ||
| 39 | +# On a Windows system, you should name the hook program | ||
| 40 | +# 'pre-revprop-change.bat' or 'pre-revprop-change.exe', | ||
| 41 | +# but the basic idea is the same. | ||
| 42 | +# | ||
| 43 | +# The hook program typically does not inherit the environment of | ||
| 44 | +# its parent process. For example, a common problem is for the | ||
| 45 | +# PATH environment variable to not be set to its usual value, so | ||
| 46 | +# that subprograms fail to launch unless invoked via absolute path. | ||
| 47 | +# If you're having unexpected problems with a hook program, the | ||
| 48 | +# culprit may be unusual (or missing) environment variables. | ||
| 49 | +# | ||
| 50 | +# Here is an example hook script, for a Unix /bin/sh interpreter. | ||
| 51 | +# For more examples and pre-written hooks, see those in | ||
| 52 | +# the Subversion repository at | ||
| 53 | +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and | ||
| 54 | +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ | ||
| 55 | + | ||
| 56 | + | ||
| 57 | +REPOS="$1" | ||
| 58 | +REV="$2" | ||
| 59 | +USER="$3" | ||
| 60 | +PROPNAME="$4" | ||
| 61 | +ACTION="$5" | ||
| 62 | + | ||
| 63 | +if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi | ||
| 64 | + | ||
| 65 | +echo "Changing revision properties other than svn:log is prohibited" >&2 | ||
| 66 | +exit 1 |
hooks/pre-unlock.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# PRE-UNLOCK HOOK | ||
| 4 | +# | ||
| 5 | +# The pre-unlock hook is invoked before an exclusive lock is | ||
| 6 | +# destroyed. Subversion runs this hook by invoking a program | ||
| 7 | +# (script, executable, binary, etc.) named 'pre-unlock' (for which | ||
| 8 | +# this file is a template), with the following ordered arguments: | ||
| 9 | +# | ||
| 10 | +# [1] REPOS-PATH (the path to this repository) | ||
| 11 | +# [2] PATH (the path in the repository about to be unlocked) | ||
| 12 | +# [3] USER (the user destroying the lock) | ||
| 13 | +# [4] TOKEN (the lock token to be destroyed) | ||
| 14 | +# [5] BREAK-UNLOCK (1 if the user is breaking the lock, else 0) | ||
| 15 | +# | ||
| 16 | +# The default working directory for the invocation is undefined, so | ||
| 17 | +# the program should set one explicitly if it cares. | ||
| 18 | +# | ||
| 19 | +# If the hook program exits with success, the lock is destroyed; but | ||
| 20 | +# if it exits with failure (non-zero), the unlock action is aborted | ||
| 21 | +# and STDERR is returned to the client. | ||
| 22 | + | ||
| 23 | +# On a Unix system, the normal procedure is to have 'pre-unlock' | ||
| 24 | +# invoke other programs to do the real work, though it may do the | ||
| 25 | +# work itself too. | ||
| 26 | +# | ||
| 27 | +# Note that 'pre-unlock' must be executable by the user(s) who will | ||
| 28 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 29 | +# have filesystem-level permission to access the repository. | ||
| 30 | +# | ||
| 31 | +# On a Windows system, you should name the hook program | ||
| 32 | +# 'pre-unlock.bat' or 'pre-unlock.exe', | ||
| 33 | +# but the basic idea is the same. | ||
| 34 | +# | ||
| 35 | +# Here is an example hook script, for a Unix /bin/sh interpreter: | ||
| 36 | + | ||
| 37 | +REPOS="$1" | ||
| 38 | +PATH="$2" | ||
| 39 | +USER="$3" | ||
| 40 | +TOKEN="$4" | ||
| 41 | +BREAK="$5" | ||
| 42 | + | ||
| 43 | +# If a lock is owned by a different person, don't allow it be broken. | ||
| 44 | +# (Maybe this script could send email to the lock owner?) | ||
| 45 | + | ||
| 46 | +SVNLOOK=/usr/local/bin/svnlook | ||
| 47 | +GREP=/bin/grep | ||
| 48 | +SED=/bin/sed | ||
| 49 | + | ||
| 50 | +LOCK_OWNER=`$SVNLOOK lock "$REPOS" "$PATH" | \ | ||
| 51 | + $GREP '^Owner: ' | $SED 's/Owner: //'` | ||
| 52 | + | ||
| 53 | +# If we get no result from svnlook, there's no lock, return success: | ||
| 54 | +if [ "$LOCK_OWNER" = "" ]; then | ||
| 55 | + exit 0 | ||
| 56 | +fi | ||
| 57 | + | ||
| 58 | +# If the person unlocking matches the lock's owner, return success: | ||
| 59 | +if [ "$LOCK_OWNER" = "$USER" ]; then | ||
| 60 | + exit 0 | ||
| 61 | +fi | ||
| 62 | + | ||
| 63 | +# Otherwise, we've got an owner mismatch, so return failure: | ||
| 64 | +echo "Error: $PATH locked by ${LOCK_OWNER}." 1>&2 | ||
| 65 | +exit 1 |
hooks/start-commit.tmpl
0 → 100644
| 1 | +#!/bin/sh | ||
| 2 | + | ||
| 3 | +# START-COMMIT HOOK | ||
| 4 | +# | ||
| 5 | +# The start-commit hook is invoked immediately after a Subversion txn is | ||
| 6 | +# created and populated with initial revprops in the process of doing a | ||
| 7 | +# commit. Subversion runs this hook by invoking a program (script, | ||
| 8 | +# executable, binary, etc.) named 'start-commit' (for which this file | ||
| 9 | +# is a template) with the following ordered arguments: | ||
| 10 | +# | ||
| 11 | +# [1] REPOS-PATH (the path to this repository) | ||
| 12 | +# [2] USER (the authenticated user attempting to commit) | ||
| 13 | +# [3] CAPABILITIES (a colon-separated list of capabilities reported | ||
| 14 | +# by the client; see note below) | ||
| 15 | +# [4] TXN-NAME (the name of the commit txn just created) | ||
| 16 | +# | ||
| 17 | +# Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5 | ||
| 18 | +# clients will typically report at least the "mergeinfo" capability. | ||
| 19 | +# If there are other capabilities, then the list is colon-separated, | ||
| 20 | +# e.g.: "mergeinfo:some-other-capability" (the order is undefined). | ||
| 21 | +# | ||
| 22 | +# Note: The TXN-NAME parameter is new in Subversion 1.8. Prior to version | ||
| 23 | +# 1.8, the start-commit hook was invoked before the commit txn was even | ||
| 24 | +# created, so the ability to inspect the commit txn and its metadata from | ||
| 25 | +# within the start-commit hook was not possible. | ||
| 26 | +# | ||
| 27 | +# The list is self-reported by the client. Therefore, you should not | ||
| 28 | +# make security assumptions based on the capabilities list, nor should | ||
| 29 | +# you assume that clients reliably report every capability they have. | ||
| 30 | +# | ||
| 31 | +# The working directory for this hook program's invocation is undefined, | ||
| 32 | +# so the program should set one explicitly if it cares. | ||
| 33 | +# | ||
| 34 | +# If the hook program exits with success, the commit continues; but | ||
| 35 | +# if it exits with failure (non-zero), the commit is stopped before | ||
| 36 | +# a Subversion txn is created, and STDERR is returned to the client. | ||
| 37 | +# | ||
| 38 | +# On a Unix system, the normal procedure is to have 'start-commit' | ||
| 39 | +# invoke other programs to do the real work, though it may do the | ||
| 40 | +# work itself too. | ||
| 41 | +# | ||
| 42 | +# Note that 'start-commit' must be executable by the user(s) who will | ||
| 43 | +# invoke it (typically the user httpd runs as), and that user must | ||
| 44 | +# have filesystem-level permission to access the repository. | ||
| 45 | +# | ||
| 46 | +# On a Windows system, you should name the hook program | ||
| 47 | +# 'start-commit.bat' or 'start-commit.exe', | ||
| 48 | +# but the basic idea is the same. | ||
| 49 | +# | ||
| 50 | +# The hook program typically does not inherit the environment of | ||
| 51 | +# its parent process. For example, a common problem is for the | ||
| 52 | +# PATH environment variable to not be set to its usual value, so | ||
| 53 | +# that subprograms fail to launch unless invoked via absolute path. | ||
| 54 | +# If you're having unexpected problems with a hook program, the | ||
| 55 | +# culprit may be unusual (or missing) environment variables. | ||
| 56 | +# | ||
| 57 | +# Here is an example hook script, for a Unix /bin/sh interpreter. | ||
| 58 | +# For more examples and pre-written hooks, see those in | ||
| 59 | +# the Subversion repository at | ||
| 60 | +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and | ||
| 61 | +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ | ||
| 62 | + | ||
| 63 | + | ||
| 64 | +REPOS="$1" | ||
| 65 | +USER="$2" | ||
| 66 | + | ||
| 67 | +commit-allower.pl --repository "$REPOS" --user "$USER" || exit 1 | ||
| 68 | +special-auth-check.py --user "$USER" --auth-level 3 || exit 1 | ||
| 69 | + | ||
| 70 | +# All checks passed, so allow the commit. | ||
| 71 | +exit 0 |
locks/db-logs.lock
0 → 100644
locks/db.lock
0 → 100644
svn.ico
0 → 100644
No preview for this file type