p4 flush

クライアントワークスペースのhaveリストを、ファイルを実際にコピーすることなく更新します。

構文規則

p4 [g-opts] flush [-f -L -n -q] [[FileSpec][revSpec] ...]

説明

p4 flushコマンドは2つの手順で構成されるp4 sync FileSpecの処理の手順2のみを実行します。

手順1: FileSpecにあるファイルリビジョンを、 ディポからクライアントワークスペースにコピーします。

手順2: ワークスペースのhaveリスト(Perforceサービスによって管理されている情報で、 どのファイルリビジョンが同期されているかを追跡するリスト)を、 新しいクライアントワークスペースの内容を反映するように更新します。

通常、この動作は望ましいものではありません。その理由は、 クライアントワークスペースのhaveリストは、常にワークスペースの実際の 内容を反映すべきだからです。ただし、haveリストがワークスペースの内容と 同期されていない場合は、p4 flushを使用して、haveリストを実際の内容に 同期させることができる場合があります。p4 flushは実際にファイルを転送するわけではないので、 p4 syncを実行するよりもずっと速く処理が行われます。

オプション

-f	flushを強制的に実行します。 Helixサーバは、クライアントワークスペースに指定リビジョンの ファイルがある場合でも、flushを実行します。
-L	スクリプト作成目的で、完全なディポシンタックスに有効なリビジョン番号を 伴って示されたファイル引数リストに対し、flushを実行します。
-n	flushを実行することなくflushの結果がどうなるかを表示します。 これにより、flushを実行する前に、期待どおりの結果が得られるかどうかを 確認することができます。
-q	サイレントモード: 通常の出力メッセージを抑止します。 エラーや例外条件に関するメッセージは抑止されません。
g-opts	「グローバルオプション」を参照してください。

使用上の注意点

ファイル引数でリビジョン指定子を使用できるか？	ファイル引数でリビジョン範囲を使用できるか？	最低限必要なアクセスレベル
はい	はい	read

• p4 flushコマンドを実行すると、ファイルをコピーすることなくhaveリストが更新され、 p4 sync-fコマンドを実行すると、haveリストに一致するようにクライアントワークスペースが更新されます。 そのため、p4 flush filesコマンドを実行してからp4 sync -f filesコマンドを実行すると、 p4 syncfilesコマンドを実行した場合とほぼ同じ結果になります。 そのため、正しくないflush操作を実行した場合であっても、そのflush操作を行ったファイルリビジョンに対して p4 sync -fコマンドを実行すれば、ほぼ完全に修正できるということになります。

  ただし、この方法でも、正しくないflush操作を完全に修正することはできません。 これは、p4 flushによって所有リストから削除されたファイルリビジョンは、 p4 sync -fコマンドの実行後もクライアントワークスペース内に残るためです。 この場合は、削除されたファイルリビジョンを、手動操作でクライアントワークスペースから 削除する必要があります。

• p4 flush このコマンドは、p4 sync -kコマンドのエイリアスです。

例

• 同じサイトで作業をする10人のユーザが、遠隔地にある同一のディポから、低速リンクを介して、 新たに同じクライアントワークスペースをセットアップする必要があるとします。 通常は各ユーザが同じp4 syncコマンドを実行しますが、帯域幅に制限がある場合は 次の方法を使用すると、処理を速く行うことができます。

  • 1人のユーザがクライアントワークスペースfirstworkspaceから p4 syncfilesを実行します。
  • 他のユーザは、ローカルOSのファイルコピーコマンドを使用して、 ユーザAのクライアントワークスペースから各自のクライアントワークスペースへ、 新たに同期されたファイルをコピーします。

  • さらに、各ユーザがp4 flush files @firstworkspaceを実行すると、 上記のステップで各自のクライアントワークスペースへコピーしたファイルと同期した、 クライアントワークスペースのhaveリストが得られます。

    p4 flushでは、低速リンク経由でのファイル転送は実行されないため、 この処理は、p4 syncコマンドを異なるタイミングで10回実行するより はるかに高速になります。

• ジョーは、
  /usr/joe/project1/subproj
  のRoot:フィールドと、
  //depot/joe/proj1/subproj/... //joe/...
  のView:フィールドを持つjoeというクライアントワークスペースを使用しています。 ジョーは、/usr/joe/project1のすべてのファイルを自分のワークスペースに含める必要があると判断し、 p4 clientを使用してRoot:フィールドを/usr/joe/project1
  に、 View:フィールドを//depot/joe/proj1/... //joe/...に変更しました。

  その結果、現在のクライアントワークスペースのファイルは同じ場所にとどまり、 ワークスペースの範囲は他のファイルも含むように拡張されました。 ところが、ジョーは次にp4 syncを実行したとき、 Helixサーバがクライアントワークスペースの非作業状態のファイルを残らず削除し、 もう一度同じファイルを同じ場所にコピーしていることを知って驚きました。

  Helixサーバがこのように動作する原因は次のとおりです。

  • haveリストは各ファイルのクライアントルートに対する相対的な位置を記述します。
  • 各ファイルの物理的位置は Helixサーバコマンドが実行されるたびに特定されます。

  このため、次のような結果になります。

  • Helixサーバは、各ファイルが再配置されたとみなします。
  • p4 sync このコマンドを実行すると、ファイルが以前の場所から削除され、 新しい場所にそのファイルがコピーされます。

  このような問題を効率的に解決するには、p4 flush #haveを使用してクライアントワークスペースのhaveリストを更新します。 これにより、実際にファイルがコピーされることなく、ファイルの新しい場所が反映されます。

  関連コマンド

  p4 flush このコマンドは、p4 sync -kコマンドのエイリアスです。	p4 sync -k
  ディポのファイルをクライアントワークスペースにコピーする	p4 sync
  正しくない方法でp4 flushが実行された場合に、 haveリストをクライアントワークスペースに同期させる	p4 sync -f