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 read-only EACL privilege on the element being promoted

•	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.

ACLs vs. EACLs

ACLs govern access to depots and streams, with broad all or none rights. EACLs govern access to individual elements in the depot, and provide finer-grained privileges for an element: Full, Allow, Read Only, and Deny. Note that if the ACL on a stream is set to none for a given user, you cannot set EACLs for elements in that stream for that user.

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 script repository).

Running trigger scripts on the server machine provides administrative simplicity and centralized logging.