ソース管理への追加操作を実行した後、ClearCase操作にかかる時間を理解しようとしています。
CCRCスナップショットビューで作業していて、ファイルをソース管理に追加した場合、変更セットが新しい行で更新されるまでにかかる時間と、操作が完了するまでの期間で、新しいファイルが動的に使用可能になります。ファイルがチェックインされたストリームを指すビュー?
動的ビューなどの手動更新を呼び出すことによって、そのプロセスを高速化する方法はありますか?
よろしく、
アンドリュー
ソース管理への追加操作を実行した後、ClearCase操作にかかる時間を理解しようとしています。
CCRCスナップショットビューで作業していて、ファイルをソース管理に追加した場合、変更セットが新しい行で更新されるまでにかかる時間と、操作が完了するまでの期間で、新しいファイルが動的に使用可能になります。ファイルがチェックインされたストリームを指すビュー?
動的ビューなどの手動更新を呼び出すことによって、そのプロセスを高速化する方法はありますか?
よろしく、
アンドリュー
チェンジセットが新しい行で更新されるまでにどのくらい時間がかかりますか
ファイルをチェックアウトしてアクティビティを選択するとすぐに、そのアクティビティのチャレンジセットがすぐに更新されます。
動的ビューは、(CCRCのWebスナップショットビューを介して)チェックインした後にのみそのファイルを反映し、その更新もほぼ瞬時に行われます。
速度を上げるには、動的ビューを更新するか、更新を確認するディレクトリでcleartoollsを実行します。
いずれの場合も、CCRCを介してチェックアウトまたはチェックインを行う場合は、httpリクエストをCCRCサーバーに送信し、CCRCサーバーがClearCase Vob/Viewサーバーでの操作を完了します。
したがって、チェックアウト/チェックインが完了すると、他のClearCaseビュー(CCRCかどうか)で変更を反映できるようになります。
時間がかかるのは、CCRCクライアントとCCRCサーバー間の通信だけです。そのサーバーは通常、ClearCaseサーバーと同じLAN上にあり、ClearCaseコマンド自体はかなり高速に実行されます。
「かなり速く」は、OPの必要性に対して遅すぎることが判明しました:チェックイン時の術後トリガー。
mkelem
そのトリガーはサーバー側でClearCase動的ビューを使用し、そのトリガーの2番目の呼び出し(チェックインされている親ディレクトリ上)が新しく作成されたファイルを適切に検出するために、要素チェックイン(オン)にスリープを導入する必要があります。
理論的には、それは瞬時でなければなりません。追加が完了するとすぐに、動的ビューに新しいファイルが表示されます。実際には、ClearCaseとそのビュープロセスの性質上、さらに時間がかかる場合があります。
すべてのビューには、ビューサーバー(ローカルまたはリモート)で実行されているプロセスがあり、このプロセスは、変更を取得するためにVOBサーバーにクエリを実行する必要があります。
ClearCase環境では、ロードされたサーバーとネットワークトラフィックの組み合わせである可能性が高い多くのラグが見られます。
結論-迅速(秒)である必要がありますが、瞬時ではありません。時間がかかる場合は、プロセスの速度を低下させている可能性があるものを確認する必要があります。