メインブランチをロックして、既存の機能やAPIの互換性を損なう変更を他人がチェックできないようにしたいと思います。私はコンポーネント内のすべてのファイルについてcleartool lock <element>@@/mainを実行しましたが、これもチェックアウト操作を防ぎます。（ベース）チェックインのClearCaseロックメインブランチ
私はブランチでのチェックアウトはまだ許されていると主張しましたが、私は非常に基本的なSCMプラクティスを持つ環境で働いています。チェックインのためにブランチをロックして、チェックアウトを許可することは可能ですか？
私が考えることができるのは、ClearCaseトリガーを設定することだけです。そこに良いオプションはありますか？
discussed in this threadとして、フォルダと要素をロックすることは理想的ではありません。
クライアントごとにポリシーを展開することなくポリシーを適用するには、引き続きトリガーを設定することが最良の方法です。
スレッドが（チェックアウトのために、同じ考え方はチェックインに適用することができます）示唆してチェックアウトを停止するには、ディレクトリにトリガー
場所をこと。
デフォルトでは、ディレクトリに「要素」トリガを配置すると、現在の要素と将来のディレクトリ要素に、その添付ファイルリストと継承リストを介して適用されます。あなたのケースでは
cleartool mktrtype -ele -preop checkout -exec /path/to/script NO_CHECKOUT
cleartool mktrigger NO_CHECKOUT /path/to/dir_name
、/path/to/script（すべてのクライアントがアクセスする必要がありますパス）（CLEARCASE_BRTYPEのように、trigger environment variablesを使用して）現在のブランチが/mainであるかどうかを確認する必要があります。
"コンポーネント"？ UCMコンポーネントのように？または、ベースClearCaseのみを使用していますか？ – VonC
@VonCベースClearCase。私はいくつかの他の出版物でこの用語を見て以来、コンポーネントという用語を使用しました。それは純粋なUCM用語ですか？ –
はい、そうです。 UCMコンポーネント。 – VonC