p4 protect は間違いなくより良い方法です。それが目的です。すべてのユーザーをグループに入れ、保護テーブルでグループのみを使用することを強くお勧めします。これにより、管理がはるかに簡単になります。
好きなレベルの粒度で保護できるので、扱いにくいわけではありません。また、2008.1 サーバー リリースには、少し異なる方法で実行できることを指定できる新しい保護機能があることにも注意してください。変更点:
#152278 **
'p4 protect' now allows specification of permission 'rights'.
Previously, 'p4 protect' only allowed using permission levels
which include the specified access (ie 'read') and also all
of its lesser permissions (ie 'read' = 'read' + 'list').
Permission rights make it possible to deny individual rights
without having to re-grant lesser rights. The new
permission rights are '=read', '=branch', '=open',
and '=write'. This functionality was previously undocumented,
and is now fully supported for 2008.1
これをロックおよびロック解除するために管理者でなければならないことに本当に問題がある場合は、2007.3 で導入された「グループ所有者」機能を確認する必要があります。これにより、非スーパー ユーザーがグループにユーザーを追加および削除できるようになります。したがって、それを保護テーブルと組み合わせます。つまり、サイト管理者に保護テーブルを設定してもらい、権限を「Rel 1.0 Authorized」という名前のグループに制限し、あなたをグループ所有者にします。次に、そのグループにユーザー (またはサブグループ) を追加および削除して、アクセスを制御できます。
トリガー オプションは可能ですが、最初にトリガーを設定するには管理者である必要があります。また、すべての提出物のパフォーマンスに影響を与える可能性もあります。これには注意が必要です。しかし、トリガーの主な問題は、トリガーを使用して、その目的のために設計された組み込み機能、つまり保護テーブルをエミュレートすることです。また、安全を確保したい場合は、他の誰かが参照ファイルを変更できないようにする何らかの方法を見つける必要があります。既存の機能をエミュレートするのは大変な作業のように思えます。