Pre-Operation Triggers

The following triggers execute a procedure before the user-requested command executes. Each of these triggers has the ability to cancel execution of the user's command. (See The Trigger Parameters File) Some of the triggers fire on the client machine, and others on the server machine. It's possible for a single command (e.g. keep) to cause triggers to fire both on the client and on the server.

Client-Side Triggers

The following pre-operation triggers fire on the client machine:

  • pre-create-trig: fires on the client machine prior to execution of an add command. It does not fire for an ln command (GUI: Paste Link), which creates a link element.)

    • The trigger script must specify the element type (directory, text, binary, or ptext) of each element to be created by the command. This overrides the element type specified with the add -E option.

  • pre-keep-trig: fires on the client machine prior to execution of a keep command.

  • pre-promote-trig: fires on the client machine prior to execution of a promote command or a purge command (GUI: Revert to Basis Version or Revert to Most Recent Version).

Back to top

Server-Side Triggers

The following pre-operation triggers fire on the server machine.

  • server_admin_trig: fires on the server machine prior to execution of certain commands. This is a repository-wide trigger — it fires no matter what depot, if any, the user's command applies to. The following commands cause server_admin_trig to fire:

    addmember

    chstream

    mkgroup

    mkws

    rmws

    authmethod

    chuser

    mkref

    reactivate

    setacl

    chdepot 
    (see note)

    chws 
    (see note)

    mkreplica

    remove

    setproperty

    chgroup

    ismember

    mksnap 
    (see note)

    rmmember

    unlock

    chpassword

    lock

    mkstream

    rmproperty

    defcomp

    chref

    lsacl

    mktrig

    rmreplica

    replica_sync

    chslice

    mkdepot

    mkuser

    rmtrig

    write_schema

    The chdepot and chws commands cause the server_admin_trig to fire twice:

    • chdepot: server_admin_trig fires once to rename the depot object (chdepot), then again to rename the depot's root-stream object (chstream).
    • chws: server_admin_trig fires once to rename the workspace object (chws), then again to rename the workspace stream object (chstream).

    It should also be noted that the mksnap command is an alias for the mkstream command. It calls the server_admin_trig once, to create the stream object (mkstream) with a type of snapshot.

    The last three commands are not standard AccuRev CLI commands:

    • The defcomp command is not visible to the user; it is used in the implementation of the include/exclude facility CLI commands incl, excl, incldo, and clear.
    • The replica_sync command recognized by the server_admin_trig trigger corresponds to the replica sync command in the CLI.
    • The write_schema command is generated by the AccuRev GUI when the Save button is clicked in the Schema Editor.

  • server_preop_trig: fires on the server machine prior to execution of certain commands. This is a depot-specific trigger — it fires only for commands that operate on the depot(s) where the trigger has been activated.The following commands cause server_preop_trig to fire:

    add

    cpkremove

    promote

    revert

    archive

    defunct

    purge  (see note)

    unarchive

    co

    keep

    reclaim

     

    cpkadd

    ln

    replica archive

     

    purge is equivalent to the GUI command Revert to Basis.

    For add or keep, the server_preop_trig script can specify the exclusive file locking state (parallel or serial) of the element(s) processed by the command. This overrides any specification made with the –E command-line option.

    The server_preop_trig script can be used to enforce a maximum file size for the add or keep commands. To see how to do this, refer to the sample server_preop_trig.pl file in the AccuRev installation examples folder.

The server_admin_trig and server_preop_trig triggers are independent of each other and are fired by different sets of commands — for a given command, only one of these triggers will fire. But these triggers can fire in addition to the triggers enabled with the mktrig command (pre-create-trig, pre-keep-trig, pre-promote-trig, and server-post-promote-trig) and the server_dispatch_post trigger.

Back to top