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