[commit] r6550 - in trunk: . conf db db/revprops db/revprops/0 db/revs db/revs/0 db/transactions db/txn-protorevs hooks locks
Author: sduplichan Date: Sat Apr 30 02:17:23 2011 New Revision: 6550 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6550
Log:
Added: trunk/README.txt trunk/conf/ trunk/conf/authz trunk/conf/passwd trunk/conf/svnserve.conf trunk/db/ trunk/db/current trunk/db/format trunk/db/fs-type trunk/db/fsfs.conf trunk/db/min-unpacked-rev trunk/db/revprops/ trunk/db/revprops/0/ trunk/db/revprops/0/0 trunk/db/revs/ trunk/db/revs/0/ trunk/db/revs/0/0 trunk/db/transactions/ trunk/db/txn-current trunk/db/txn-current-lock trunk/db/txn-protorevs/ trunk/db/uuid trunk/db/write-lock trunk/format trunk/hooks/ trunk/hooks/post-commit.tmpl trunk/hooks/post-lock.tmpl trunk/hooks/post-revprop-change.tmpl trunk/hooks/post-unlock.tmpl trunk/hooks/pre-commit.tmpl trunk/hooks/pre-lock.tmpl trunk/hooks/pre-revprop-change.tmpl trunk/hooks/pre-unlock.tmpl trunk/hooks/start-commit.tmpl trunk/locks/ trunk/locks/db-logs.lock trunk/locks/db.lock
Added: trunk/README.txt ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/README.txt Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,5 @@ +This is a Subversion repository; use the 'svnadmin' tool to examine +it. Do not add, delete, or modify files here unless you know how +to avoid corrupting the repository. + +Visit http://subversion.tigris.org/ for more information.
Added: trunk/conf/authz ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/conf/authz Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,32 @@ +### This file is an example authorization file for svnserve. +### Its format is identical to that of mod_authz_svn authorization +### files. +### As shown below each section defines authorizations for the path and +### (optional) repository specified by the section name. +### The authorizations follow. An authorization line can refer to: +### - a single user, +### - a group of users defined in a special [groups] section, +### - an alias defined in a special [aliases] section, +### - all authenticated users, using the '$authenticated' token, +### - only anonymous users, using the '$anonymous' token, +### - anyone, using the '*' wildcard. +### +### A match can be inverted by prefixing the rule with '~'. Rules can +### grant read ('r') access, read-write ('rw') access, or no access +### (''). + +[aliases] +# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average + +[groups] +# harry_and_sally = harry,sally +# harry_sally_and_joe = harry,sally,&joe + +# [/foo/bar] +# harry = rw +# &joe = r +# * = + +# [repository:/baz/fuz] +# @harry_and_sally = rw +# * = r
Added: trunk/conf/passwd ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/conf/passwd Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,8 @@ +### This file is an example password file for svnserve. +### Its format is similar to that of svnserve.conf. As shown in the +### example below it contains one section labelled [users]. +### The name and password for each user follow, one account per line. + +[users] +# harry = harryssecret +# sally = sallyssecret
Added: trunk/conf/svnserve.conf ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/conf/svnserve.conf Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,47 @@ +### This file controls the configuration of the svnserve daemon, if you +### use it to allow access to this repository. (If you only allow +### access through http: and/or file: URLs, then this file is +### irrelevant.) + +### Visit http://subversion.tigris.org/ for more information. + +[general] +### These options control access to the repository for unauthenticated +### and authenticated users. Valid values are "write", "read", +### and "none". The sample settings below are the defaults. +# anon-access = read +# auth-access = write +### The password-db option controls the location of the password +### database file. Unless you specify a path starting with a /, +### the file's location is relative to the directory containing +### this configuration file. +### If SASL is enabled (see below), this file will NOT be used. +### Uncomment the line below to use the default password file. +# password-db = passwd +### The authz-db option controls the location of the authorization +### rules for path-based access control. Unless you specify a path +### starting with a /, the file's location is relative to the the +### directory containing this file. If you don't specify an +### authz-db, no path-based access control is done. +### Uncomment the line below to use the default authorization file. +# authz-db = authz +### This option specifies the authentication realm of the repository. +### If two repositories have the same authentication realm, they should +### have the same password database, and vice versa. The default realm +### is repository's uuid. +# realm = My First Repository + +[sasl] +### This option specifies whether you want to use the Cyrus SASL +### library for authentication. Default is false. +### This section will be ignored if svnserve is not built with Cyrus +### SASL support; to check, run 'svnserve --version' and look for a line +### reading 'Cyrus SASL authentication is available.' +# use-sasl = true +### These options specify the desired strength of the security layer +### that you want SASL to provide. 0 means no encryption, 1 means +### integrity-checking only, values larger than 1 are correlated +### to the effective key length for encryption (e.g. 128 means 128-bit +### encryption). The values below are the defaults. +# min-encryption = 0 +# max-encryption = 256
Added: trunk/db/current ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/current Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1 @@ +0
Added: trunk/db/format ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/format Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,2 @@ +4 +layout sharded 1000
Added: trunk/db/fs-type ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/fs-type Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1 @@ +fsfs
Added: trunk/db/fsfs.conf ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/fsfs.conf Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,37 @@ +### 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 performace, +### 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. +# enable-rep-sharing = false
Added: trunk/db/min-unpacked-rev ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/min-unpacked-rev Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1 @@ +0
Added: trunk/db/revprops/0/0 ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/revprops/0/0 Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,5 @@ +K 8 +svn:date +V 27 +2011-04-30T00:14:47.187500Z +END
Added: trunk/db/revs/0/0 ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/revs/0/0 Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,11 @@ +PLAIN +END +ENDREP +id: 0.0.r0/17 +type: dir +count: 0 +text: 0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e +cpath: / + + +17 107
Added: trunk/db/txn-current ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/txn-current Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1 @@ +0
Added: trunk/db/txn-current-lock ==============================================================================
Added: trunk/db/uuid ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/db/uuid Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1 @@ +7b0d0e46-80a8-c348-a770-6b5674e485c0
Added: trunk/db/write-lock ==============================================================================
Added: trunk/format ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/format Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1 @@ +5
Added: trunk/hooks/post-commit.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/post-commit.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,50 @@ +#!/bin/sh + +# POST-COMMIT HOOK +# +# The post-commit hook is invoked after a commit. Subversion runs +# this hook by invoking a program (script, executable, binary, etc.) +# named 'post-commit' (for which this file is a template) with the +# following ordered arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] REV (the number of the revision just committed) +# +# The default working directory for the invocation is undefined, so +# the program should set one explicitly if it cares. +# +# Because the commit has already completed and cannot be undone, +# the exit code of the hook program is ignored. The hook program +# can use the 'svnlook' utility to help it examine the +# newly-committed tree. +# +# On a Unix system, the normal procedure is to have 'post-commit' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# Note that 'post-commit' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'post-commit.bat' or 'post-commit.exe', +# but the basic idea is the same. +# +# The hook program typically does not inherit the environment of +# its parent process. For example, a common problem is for the +# PATH environment variable to not be set to its usual value, so +# that subprograms fail to launch unless invoked via absolute path. +# If you're having unexpected problems with a hook program, the +# culprit may be unusual (or missing) environment variables. +# +# Here is an example hook script, for a Unix /bin/sh interpreter. +# For more examples and pre-written hooks, see those in +# the Subversion repository at +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ + + +REPOS="$1" +REV="$2" + +mailer.py commit "$REPOS" "$REV" /path/to/mailer.conf
Added: trunk/hooks/post-lock.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/post-lock.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,44 @@ +#!/bin/sh + +# POST-LOCK HOOK +# +# The post-lock hook is run after a path is locked. Subversion runs +# this hook by invoking a program (script, executable, binary, etc.) +# named 'post-lock' (for which this file is a template) with the +# following ordered arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] USER (the user who created the lock) +# +# The paths that were just locked are passed to the hook via STDIN (as +# of Subversion 1.2, only one path is passed per invocation, but the +# plan is to pass all locked paths at once, so the hook program +# should be written accordingly). +# +# The default working directory for the invocation is undefined, so +# the program should set one explicitly if it cares. +# +# Because the lock has already been created and cannot be undone, +# the exit code of the hook program is ignored. The hook program +# can use the 'svnlook' utility to help it examine the +# newly-created lock. +# +# On a Unix system, the normal procedure is to have 'post-lock' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# Note that 'post-lock' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'post-lock.bat' or 'post-lock.exe', +# but the basic idea is the same. +# +# Here is an example hook script, for a Unix /bin/sh interpreter: + +REPOS="$1" +USER="$2" + +# Send email to interested parties, let them know a lock was created: +mailer.py lock "$REPOS" "$USER" /path/to/mailer.conf
Added: trunk/hooks/post-revprop-change.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/post-revprop-change.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,56 @@ +#!/bin/sh + +# POST-REVPROP-CHANGE HOOK +# +# The post-revprop-change hook is invoked after a revision property +# has been added, modified or deleted. Subversion runs this hook by +# invoking a program (script, executable, binary, etc.) named +# 'post-revprop-change' (for which this file is a template), with the +# following ordered arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] REV (the revision that was tweaked) +# [3] USER (the username of the person tweaking the property) +# [4] PROPNAME (the property that was changed) +# [5] ACTION (the property was 'A'dded, 'M'odified, or 'D'eleted) +# +# [STDIN] PROPVAL ** the old property value is passed via STDIN. +# +# Because the propchange has already completed and cannot be undone, +# the exit code of the hook program is ignored. The hook program +# can use the 'svnlook' utility to help it examine the +# new property value. +# +# On a Unix system, the normal procedure is to have 'post-revprop-change' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# Note that 'post-revprop-change' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'post-revprop-change.bat' or 'post-revprop-change.exe', +# but the basic idea is the same. +# +# The hook program typically does not inherit the environment of +# its parent process. For example, a common problem is for the +# PATH environment variable to not be set to its usual value, so +# that subprograms fail to launch unless invoked via absolute path. +# If you're having unexpected problems with a hook program, the +# culprit may be unusual (or missing) environment variables. +# +# Here is an example hook script, for a Unix /bin/sh interpreter. +# For more examples and pre-written hooks, see those in +# the Subversion repository at +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ + + +REPOS="$1" +REV="$2" +USER="$3" +PROPNAME="$4" +ACTION="$5" + +mailer.py propchange2 "$REPOS" "$REV" "$USER" "$PROPNAME" "$ACTION" /path/to/mailer.conf
Added: trunk/hooks/post-unlock.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/post-unlock.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,42 @@ +#!/bin/sh + +# POST-UNLOCK HOOK +# +# The post-unlock hook runs after a path is unlocked. Subversion runs +# this hook by invoking a program (script, executable, binary, etc.) +# named 'post-unlock' (for which this file is a template) with the +# following ordered arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] USER (the user who destroyed the lock) +# +# The paths that were just unlocked are passed to the hook via STDIN +# (as of Subversion 1.2, only one path is passed per invocation, but +# the plan is to pass all unlocked paths at once, so the hook program +# should be written accordingly). +# +# The default working directory for the invocation is undefined, so +# the program should set one explicitly if it cares. +# +# Because the lock has already been destroyed and cannot be undone, +# the exit code of the hook program is ignored. +# +# On a Unix system, the normal procedure is to have 'post-unlock' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# Note that 'post-unlock' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'post-unlock.bat' or 'post-unlock.exe', +# but the basic idea is the same. +# +# Here is an example hook script, for a Unix /bin/sh interpreter: + +REPOS="$1" +USER="$2" + +# Send email to interested parties, let them know a lock was removed: +mailer.py unlock "$REPOS" "$USER" /path/to/mailer.conf
Added: trunk/hooks/pre-commit.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/pre-commit.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,81 @@ +#!/bin/sh + +# PRE-COMMIT HOOK +# +# The pre-commit hook is invoked before a Subversion txn is +# committed. Subversion runs this hook by invoking a program +# (script, executable, binary, etc.) named 'pre-commit' (for which +# this file is a template), with the following ordered arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] TXN-NAME (the name of the txn about to be committed) +# +# [STDIN] LOCK-TOKENS ** the lock tokens are passed via STDIN. +# +# If STDIN contains the line "LOCK-TOKENS:\n" (the "\n" denotes a +# single newline), the lines following it are the lock tokens for +# this commit. The end of the list is marked by a line containing +# only a newline character. +# +# Each lock token line consists of a URI-escaped path, followed +# by the separator character '|', followed by the lock token string, +# followed by a newline. +# +# The default working directory for the invocation is undefined, so +# the program should set one explicitly if it cares. +# +# If the hook program exits with success, the txn is committed; but +# if it exits with failure (non-zero), the txn is aborted, no commit +# takes place, and STDERR is returned to the client. The hook +# program can use the 'svnlook' utility to help it examine the txn. +# +# On a Unix system, the normal procedure is to have 'pre-commit' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# *** NOTE: THE HOOK PROGRAM MUST NOT MODIFY THE TXN, EXCEPT *** +# *** FOR REVISION PROPERTIES (like svn:log or svn:author). *** +# +# This is why we recommend using the read-only 'svnlook' utility. +# In the future, Subversion may enforce the rule that pre-commit +# hooks should not modify the versioned data in txns, or else come +# up with a mechanism to make it safe to do so (by informing the +# committing client of the changes). However, right now neither +# mechanism is implemented, so hook writers just have to be careful. +# +# Note that 'pre-commit' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'pre-commit.bat' or 'pre-commit.exe', +# but the basic idea is the same. +# +# The hook program typically does not inherit the environment of +# its parent process. For example, a common problem is for the +# PATH environment variable to not be set to its usual value, so +# that subprograms fail to launch unless invoked via absolute path. +# If you're having unexpected problems with a hook program, the +# culprit may be unusual (or missing) environment variables. +# +# Here is an example hook script, for a Unix /bin/sh interpreter. +# For more examples and pre-written hooks, see those in +# the Subversion repository at +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ + + +REPOS="$1" +TXN="$2" + +# Make sure that the log message contains some text. +SVNLOOK=/usr/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
Added: trunk/hooks/pre-lock.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/pre-lock.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,71 @@ +#!/bin/sh + +# PRE-LOCK HOOK +# +# The pre-lock hook is invoked before an exclusive lock is +# created. Subversion runs this hook by invoking a program +# (script, executable, binary, etc.) named 'pre-lock' (for which +# this file is a template), with the following ordered arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] PATH (the path in the repository about to be locked) +# [3] USER (the user creating the lock) +# [4] COMMENT (the comment of the lock) +# [5] STEAL-LOCK (1 if the user is trying to steal the lock, else 0) +# +# If the hook program outputs anything on stdout, the output string will +# be used as the lock token for this lock operation. If you choose to use +# this feature, you must guarantee the tokens generated are unique across +# the repository each time. +# +# The default working directory for the invocation is undefined, so +# the program should set one explicitly if it cares. +# +# If the hook program exits with success, the lock is created; but +# if it exits with failure (non-zero), the lock action is aborted +# and STDERR is returned to the client. + +# On a Unix system, the normal procedure is to have 'pre-lock' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# Note that 'pre-lock' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'pre-lock.bat' or 'pre-lock.exe', +# but the basic idea is the same. +# +# Here is an example hook script, for a Unix /bin/sh interpreter: + +REPOS="$1" +PATH="$2" +USER="$3" + +# If a lock exists and is owned by a different person, don't allow it +# to be stolen (e.g., with 'svn lock --force ...'). + +# (Maybe this script could send email to the lock owner?) +SVNLOOK=/usr/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
Added: trunk/hooks/pre-revprop-change.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/pre-revprop-change.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,66 @@ +#!/bin/sh + +# PRE-REVPROP-CHANGE HOOK +# +# The pre-revprop-change hook is invoked before a revision property +# is added, modified or deleted. Subversion runs this hook by invoking +# a program (script, executable, binary, etc.) named 'pre-revprop-change' +# (for which this file is a template), with the following ordered +# arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] REVISION (the revision being tweaked) +# [3] USER (the username of the person tweaking the property) +# [4] PROPNAME (the property being set on the revision) +# [5] ACTION (the property is being 'A'dded, 'M'odified, or 'D'eleted) +# +# [STDIN] PROPVAL ** the new property value is passed via STDIN. +# +# If the hook program exits with success, the propchange happens; but +# if it exits with failure (non-zero), the propchange doesn't happen. +# The hook program can use the 'svnlook' utility to examine the +# existing value of the revision property. +# +# WARNING: unlike other hooks, this hook MUST exist for revision +# properties to be changed. If the hook does not exist, Subversion +# will behave as if the hook were present, but failed. The reason +# for this is that revision properties are UNVERSIONED, meaning that +# a successful propchange is destructive; the old value is gone +# forever. We recommend the hook back up the old value somewhere. +# +# On a Unix system, the normal procedure is to have 'pre-revprop-change' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# Note that 'pre-revprop-change' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'pre-revprop-change.bat' or 'pre-revprop-change.exe', +# but the basic idea is the same. +# +# The hook program typically does not inherit the environment of +# its parent process. For example, a common problem is for the +# PATH environment variable to not be set to its usual value, so +# that subprograms fail to launch unless invoked via absolute path. +# If you're having unexpected problems with a hook program, the +# culprit may be unusual (or missing) environment variables. +# +# Here is an example hook script, for a Unix /bin/sh interpreter. +# For more examples and pre-written hooks, see those in +# the Subversion repository at +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ + + +REPOS="$1" +REV="$2" +USER="$3" +PROPNAME="$4" +ACTION="$5" + +if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi + +echo "Changing revision properties other than svn:log is prohibited" >&2 +exit 1
Added: trunk/hooks/pre-unlock.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/pre-unlock.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,63 @@ +#!/bin/sh + +# PRE-UNLOCK HOOK +# +# The pre-unlock hook is invoked before an exclusive lock is +# destroyed. Subversion runs this hook by invoking a program +# (script, executable, binary, etc.) named 'pre-unlock' (for which +# this file is a template), with the following ordered arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] PATH (the path in the repository about to be unlocked) +# [3] USER (the user destroying the lock) +# [4] TOKEN (the lock token to be destroyed) +# [5] BREAK-UNLOCK (1 if the user is breaking the lock, else 0) +# +# The default working directory for the invocation is undefined, so +# the program should set one explicitly if it cares. +# +# If the hook program exits with success, the lock is destroyed; but +# if it exits with failure (non-zero), the unlock action is aborted +# and STDERR is returned to the client. + +# On a Unix system, the normal procedure is to have 'pre-unlock' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# Note that 'pre-unlock' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'pre-unlock.bat' or 'pre-unlock.exe', +# but the basic idea is the same. +# +# Here is an example hook script, for a Unix /bin/sh interpreter: + +REPOS="$1" +PATH="$2" +USER="$3" + +# If a lock is owned by a different person, don't allow it be broken. +# (Maybe this script could send email to the lock owner?) + +SVNLOOK=/usr/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
Added: trunk/hooks/start-commit.tmpl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/hooks/start-commit.tmpl Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,65 @@ +#!/bin/sh + +# START-COMMIT HOOK +# +# The start-commit hook is invoked before a Subversion txn is created +# in the process of doing a commit. Subversion runs this hook +# by invoking a program (script, executable, binary, etc.) named +# 'start-commit' (for which this file is a template) +# with the following ordered arguments: +# +# [1] REPOS-PATH (the path to this repository) +# [2] USER (the authenticated user attempting to commit) +# [3] CAPABILITIES (a colon-separated list of capabilities reported +# by the client; see note below) +# +# Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5 +# clients will typically report at least the "mergeinfo" capability. +# If there are other capabilities, then the list is colon-separated, +# e.g.: "mergeinfo:some-other-capability" (the order is undefined). +# +# The list is self-reported by the client. Therefore, you should not +# make security assumptions based on the capabilities list, nor should +# you assume that clients reliably report every capability they have. +# +# The working directory for this hook program's invocation is undefined, +# so the program should set one explicitly if it cares. +# +# If the hook program exits with success, the commit continues; but +# if it exits with failure (non-zero), the commit is stopped before +# a Subversion txn is created, and STDERR is returned to the client. +# +# On a Unix system, the normal procedure is to have 'start-commit' +# invoke other programs to do the real work, though it may do the +# work itself too. +# +# Note that 'start-commit' must be executable by the user(s) who will +# invoke it (typically the user httpd runs as), and that user must +# have filesystem-level permission to access the repository. +# +# On a Windows system, you should name the hook program +# 'start-commit.bat' or 'start-commit.exe', +# but the basic idea is the same. +# +# The hook program typically does not inherit the environment of +# its parent process. For example, a common problem is for the +# PATH environment variable to not be set to its usual value, so +# that subprograms fail to launch unless invoked via absolute path. +# If you're having unexpected problems with a hook program, the +# culprit may be unusual (or missing) environment variables. +# +# Here is an example hook script, for a Unix /bin/sh interpreter. +# For more examples and pre-written hooks, see those in +# the Subversion repository at +# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and +# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ + + +REPOS="$1" +USER="$2" + +commit-allower.pl --repository "$REPOS" --user "$USER" || exit 1 +special-auth-check.py --user "$USER" --auth-level 3 || exit 1 + +# All checks passed, so allow the commit. +exit 0
Added: trunk/locks/db-logs.lock ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/locks/db-logs.lock Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,3 @@ +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.
Added: trunk/locks/db.lock ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/locks/db.lock Sat Apr 30 02:17:23 2011 (r6550) @@ -0,0 +1,3 @@ +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.
Sorry about that commit. I am trying to make a local svn so that I can incrementally apply a large change set and end up with a series of patches instead of one huge patch. Executing TortoiseSVN import on my local machine wrote to the remote repository without warning, something I was not expecting.
I have changes ready for AMD Persimmon that support Windows 7. Windows XP and linux.
Thanks, ScottD
"Scott Duplichan" scott@notabs.org writes:
Sorry about that commit. I am trying to make a local svn so that I can incrementally apply a large change set and end up with a series of patches instead of one huge patch. Executing TortoiseSVN import on my local machine wrote to the remote repository without warning, something I was not expecting.
That sound like yet another reason to switch coreboot to git :)
SCNR,
Sven.
Am 30.04.2011 15:53, schrieb Sven Schnelle:
That sound like yet another reason to switch coreboot to git :)
We already provide a mirror that people can use. Obviously, git isn't attractive enough to migrate people over.
When looking for new tools we should also consider fossil, monotone, hg, bzr, darcs, tla, codeville (and many many more), most of which predate git while providing a nicer UI and a more clearly defined data model.
On the other hand, we still use IRC and mailing lists, so to match the age of our SCM with that of the other tools, maybe we should migrate to tarballs (or sccs, at most!)?
Patrick
Scott Duplichan wrote:
Sorry about that commit. I am trying to make a local svn so that I can incrementally apply a large change set and end up with a series of patches instead of one huge patch.
This isn't really supported by Subversion. But as Sven points out, it's very much possible with git. I would be happy to help you withh this Scott, but to be efficient I think we should maybe work via IRC or some other form of instant messaging (jabber and MSN would be easy for me, or even SIP). The process outline is:
1. git clone git://code.coreboot.org/coreboot-git.git 2. cd coreboot-git 3. git checkout -b largechangeset [commitid] 4. git apply largechangeset.patch 5. git add -i 6. git commit 7. goto 5. until completed 8. [potential extra steps, see notes] 9. git format-patch master..
Notes on this:
Step 5. is where you will spend potentially a lot of time to pick out the parts of largechangeset.patch that you want to include in each commit. Use the p command to say that you want to select what patch hunks should be added. Then it asks which files you want to process for the current commit. Can use lists and spans. 1,4 or 1-20 or 1,3,6-9 The selected files are marked with * and when all files you want to process are marked with * just hit enter at the Patch update>> prompt. Then git add -i will show you each hunk in each file, and you can say if you want to add it all or skip it all or abort the entire operation or you can even edit this hunk to get only what you want for this commit. Please read the git add man-page for much better info on "interactive add" as this is called.
Note that it's easy to run git add -i again to add more hunks before making the commit, in fact I think it's easier than selectively "un-add" stuff that has been added, but maybe my git-fu is just weak there. Also note that if you must edit some hunks then things are inherently a little more complicated if you don't get the hunk just right the first time. Then I would suggest to [r]evert (in git add -i) the entire hunk and try again with [p]atch.
If largechangeset.patch applies cleanly only to an older revision you want to specify the git commit id for that revision as commitid in 3. Given svn rev 6551, the corresponding git commit can be found using:
git log -1 --grep svn://svn.coreboot.org/coreboot/trunk@6551
The commit id is on the first line of output.
If doing this and want to forward-port changes to current trunk, then an extra step is needed in 8. as follows:
8.1.1. git rebase master
During this rebase there may be some conflicts that need to be resolved:
8.1.2. edit source to resolve conflicts 8.1.3. git rebase --continue 8.1.4. repeat from 8.2.
But if there are no conflicts then the rebase is automatic.
Another potential extra step is that you may want to make some changes to your commits before generating the patches:
8.2.1. git rebase -i master
This allows to combine commits, rewrite commit messages, or change the contents of the actual commits. I personally find it easier to use interactive rebase to fix things up than to get the interactive add exactly right when multiple commits are heavily intertwined.
Again have a look at git rebase --help under INTERACTIVE, for more complete description of what this can do. It's pretty powerful.
Feel free to ask questions.
Patrick Georgi wrote:
We already provide a mirror that people can use. Obviously, git isn't attractive enough to migrate people over.
You know better than this. :) In fact I'm pretty sure that those who already use git are already using the mirror, I know I find it very handy, but officially (from coreboot) it is still the second class citizen. I think we can only know how attractive it is if and when a switch is made. Unfortunately it may not be as easy to keep svn as a second class citizen if the main repo is using git.
Ie. those who already like git have already migrated, and the rest will need a gentle push.
//Peter
-
Patrick Georgi -
Peter Stuge -
repository service -
Scott Duplichan -
Sven Schnelle