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 sync filesを実行します。
  • 他のユーザは、ローカルOSのファイルコピーコマンドを使用して、ユーザAのクライアントワークスペースから各自のクライアントワークスペースへ、新たに同期されたファイルをコピーします。

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

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

• ジョーは、joeというクライアントワークスペースを使用しており、[Root:]フィールドは
  /usr/joe/project1/subproj
  、[View:]フィールドは
  //depot/joe/proj1/subproj/... //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
  正しくない方法でが実行された場合に、haveリストをクライアントワークスペースに同期させる。 p4 flush	p4 sync -f