[Mon Mar  5 22:47:34 PST 2001]

I’ve been testing this by taking two copies of the bitcluster tree, stuff the triggers into there, and testing on work and disks. I need to write some tests but have not done so yet.

[Thu Dec 14 19:40:09 PST 2000]
Basic trigger overview.

Event classes
    pre-commit
	- called before a changeset is committed
    	- exit !0 fails the commit
	- typically used for integrity checks
    post-commit
	- called after a changeset is committed
	- typically used for notification
    pre-incoming
	- called before an incoming push/pull is started
    	- exit !0 fails the incoming event
	- typically used for locking down a repository
    pre-resolve
	- called after the data has been union-ed in the RESYNC directory
	- called in the RESYNC directory, not the enclosing repository
	- exit 0 allows the pull/push
	- exit 1 fails the entire pull/push
	- exit 2 fails the entire pull/push but leaves the patch in PENDING
	- typically used to examine changes before taking them
    pre-apply [ NOT IMPLEMENTED ]
	- called in the RESYNC directory, not the enclosing repository
	- called after the data has been merged in the RESYNC directory
	  but before it is applied to the tree.  Last chance to say no,
	  allows examination of the merge changes
	- exit 0 allows the pull/push
	- exit 1 fails the entire pull/push
	- exit 2 fails the pull/push but leaves the patch in PENDING
	- exit 3 fails the pull/push but leaves the patch in PENDING and
	  the RESYNC tree in PENDING/RESYNC-<date>
	- typically used to examine changes before taking them
    post-incoming
	- called after the data has been applied to the tree
	- typically used for notification
    pre-outgoing
	- called before an outgoing pull/push/clone event
	- exit !0 fails the outgoing event
	- typically used for locking down a repository
    post-outgoing
	- called after the outgoing event
	- typically used for notification

Missing triggers
    - post-resolve; unlikely to be added, use pre-apply.
    - post-apply; unlikely to be added, use post-incoming
    - pre-delta; not implemented, will be implemented at some point
      We need this for spelling/cstyle/whatever checks.

Difference between pre- and post-
    pre-triggers may cause events to fail;
    post-triggers are informational only.

Paranoid mode for gatekeeper trees
    Because triggers can propagate and because they can do bad things like
    "rm -rf .", it is a wise idea to put a non-propagating paranoid trigger
    like so in your tree:

    cat > BitKeeper/triggers/pre-apply-paranoid <<EOF
    #!/bin/sh

    # This is running in the RESYNC tree, we're looking for any new
    # triggers and/or changes to triggers.
    # Done after the resolve stage because they could be sneaky and create
    # the file in an earlier changeset and then move it and we'd miss it
    # because it hasn't been moved yet.
    test `bk sfiles BitKeeper/triggers | wc -l` -gt 0 && {
    	echo Changes delayed until they are reviewed
	exit 3
    }
    exit 0


Trigger categories:
    c-	-> pre-commit
    c+  -> post-commit
    i-  -> pre-incoming
    i+  -> post-incoming
    o-  -> pre-outgoing
    o+  -> post-outgoing
    r-  -> pre-resolve

Trigger variable	Valid in	Meaning
----------------	--------	-------
BK_CSETLIST		i+, o-, r-	File containing list of cset revs.

BK_CSETS		o-, o+		List of outgoing csets.

BK_EVENT		All		Event type, such as clone.

BK_HOST			All		Client host
BKD_HOST		i-, i+, o-, o+	Server host

BK_LEVEL		All		The "level" of the client repository.
BKD_LEVEL		i+, o-, o+	The "level" of the server repository.

BK_LOCALCSETS		o-, o+		The number of csets in outgoing repo
					not found in incoming repo.

BK_PENDING		c-, c+		File containing the list of deltas
					about to be committed.

BK_REMOTECSETS		o-, o+		The number of csets in incoming repo
					not found in outgoing repo.

BK_ROOT			All		Client root
BKD_ROOT		i-, i+, o-, o+	Server root

BK_SIDE			i-, i+, o-, o+	client|server, indicates which side is
					running the trigger.

BK_STATUS		c+, i+, o+	OK means the command worked,
					other values mean an error or a
					dry run.

BK_TIME_T		All		Date of the BK binary as a time_t.
BKD_TIME_T		i-, i+, o-, o+	Date of server BK binary as a time_t.

BK_TRIGGER		All		The basename of the trigger program.

BK_USER			All		Client user
BKD_USER		i-, i+, o-, o+	Server user

BK_UTC			All		Date of the BK binary as YYYYMMDDHHMMSS
BKD_UTC			i-, i+, o-, o+	Date of the server BK binary

BK_VERSION		All		Version of the BK binary as the version
					string which may be a symbolic tag.  If
					the BK version was not tagged, then the
					UTC.
BKD_VERSION		i-, i+, o-, o+	Version of the server BK binary.