While you are able to define ACLs for each member, this introduces additional administrative work in terms of having to restrict or allow access for every file in your development project. The basic recommendation is to configure ACLs on a project by project basis specifying principals—groups or users—and keeping any hierarchies of ACLs relatively flat.

Member-related permissions provide a fine level of control and are useful when you need to restrict user access to certain key files within a project. For example, you may want to restrict access to the make file of your development project or to the index file of your Web site.

Using the configuration management policy for Force Check of FetchRevision Permission, you can also force a check of the FetchRevision permission for all configuration management member commands. If set to true, the FetchRevision permission in the ACLs is checked for each member whenever a user creates a new Sandbox, resynchronizes a member, checks out a member unlocked, or tries to view the contents of a member revision. The default setting for the policy is false. For more information, see the Force Check of FetchRevision Permission policy in General Policies.