Which Security Feature Should I Use?
AccuRev's security features overlap to a considerable extent. For example, when a user invokes the promote command, any of these mechanisms can prevent the command from proceeding:
a lock on the source or destination stream
an ACL permission on the destination stream, on a higher-level stream, or on the entire depot
a pre-promote-trig trigger script, which runs on the client machine
a server_preop_trig trigger script, which runs on the server machine
How do you decide which feature to use in a given situation? There are no absolute rules, but here are some guidelines:
To script or not to script?
The trigger mechanism depends on execution of user-supplied scripts, written in Perl, Python, or some other scripting language. There's a trade-off: scripting required development time and significant expertise, but is infinitely flexible.
In many situations, you may be able to use the AccuRev software distribution's sample Perl scripts, which are designed for fill-in-the-blanks customization.
It makes sense to implement as much security as possible with locks and ACL permissions (and perhaps the sample trigger scripts), before delving into original trigger scripting.
Locks vs. ACL permissions
Roughly speaking, a lock controls the placing of data into a stream, whereas an ACL permission controls the reading of data from a stream. (There are plenty of exceptions to this general rule.)
Both locks and permissions can be targeted at specific users or groups. The ACL is more flexible: you can create any number of permissions for the same stream, but only limited number of locks.
Running trigger scripts: client machine vs. server machine
Running trigger scripts on the client machine conserves networking and server resources. But keep in mind that all client machines must have copies of the scripts (or must have network access to a central location where scripts are kept).
Running trigger scripts on the server machine provides administrative simplicity and centralized logging.