p4 flush
概要
クライアントワークスペースのhaveリストを、ファイルを実際にコピーすることなく更新します。
構文
p4 [g-opts
] flush [-f -L -n -q]
[file
[revRange
]
…]
解説
Warning
p4 flushは、使用方法を誤ると重大な結果をもたらす危険性があります。
p4 flushを不適切に使用すると、バージョン化サービスのメタデータがクライアントワークスペースの実際の状態を反映しなくなり、以後、実行するPerforceコマンドが、意図したファイルに対して働かなくなります。p4 flushは、その目的を十分に理解するまで使用しないでください。
なお、p4 flushはほとんど使用する必要のないコマンドです。
p4 flushコマンドは、p4 syncの機能を半分だけ実行します。p4 syncfilespec
を実行すると、次の2つの処理が行われます。
-
filespec
にあるファイルリビジョンを、ディポからクライアントワークスペースにコピーします。 -
ワークスペースのhaveリスト(Perforceサービスによって管理されている情報で、どのファイルリビジョンが同期されているかを追跡するリスト)を、新しいクライアントワークスペースの内容を反映するように更新します。
p4 flushは、このうち2つ目の処理だけを実行します。通常、この動作は望ましいものではありません。その理由は、クライアントワークスペースのhaveリストは、常にワークスペースの実際の内容を反映すべきだからです。しかし、haveリストがもはやワークスペースの内容と同期していないときに、p4 flushを使用して、haveリストを実際の内容に同期させることができる場合があります。p4 flushは実際にファイルを転送するわけではないので、p4 syncの実行よりもずっと速く処理が済みます。
p4 flushは、haveリストをクライアントワークスペースの実際の状態に合わせて更新する必要がある場合にのみ、使用してください。例のセクションに、そのような場合の例を2つ示してあります。
オプション
|
flushを強制実行します。Perforceはクライアントワークスペースに指定リビジョンのファイルがある場合でもflushを実行します。ファイルが書き込み可能である場合には上書きされます。
このオプションは作業状態のファイルには影響しませんが、 |
|
スクリプト作成目的で、完全なディポシンタックスに有効なリビジョン番号を伴って示されたファイル引数リストに対し、flushを実行します。 |
|
flushを実行することなくflushの結果を表示します。これにより、flushを実行する前に、期待どおりの結果が得られるかどうかを確認することができます。 |
|
サイレントモード: 通常の出力メッセージを抑止します。エラーや例外条件に関するメッセージは抑止されません。 |
|
「“グローバルオプション”」を参照してください。 |
使用上の留意点
ファイル引数にリビジョン指定子を使えるか? |
ファイル引数にリビジョン範囲を使えるか? |
最低限必要なアクセスレベル |
---|---|---|
使用可 |
使用可 |
|
-
p4 flushは、ファイルをコピーすることなくクライアントワークスペースのhaveリストを更新します。一方、p4 sync -fは、クライアントワークスペースの内容をそのhaveリストに一致させます。したがって、p4 flush
files
に続いてp4 sync -ffiles
を実行すれば、p4 syncfiles
を実行したのとほぼ同じことになります。これは、不適切なflushが行われても、後でそのflushが行われたファイルリビジョンに対してp4 sync -fを実行すれば、ほぼ完全に修正ができることを意味しています。しかし、残念ながら、これでも完全には不適切なflushを防げません。p4 flushによって所有リストから削除されたファイルリビジョンは、p4 sync -f実行後もクライアントワークスペースに残ります。この場合には、削除されたファイルリビジョンを、手動操作でクライアントワークスペースから削除するしかありません。
-
p4 flushはp4 sync -kと同等に機能します。
例
-
同じサイトで作業をする10人のユーザが、遠隔地にある同一のディポから、低速リンクを介して、新たに同じクライアントワークスペースをセットアップする必要があるとします。通常は、各ユーザが、p4 syncコマンドを同じ構文で実行する方法をとりますが、帯域幅に制限がある場合は、次のようにすると、処理を速く済ませることができます。
-
1人のユーザ(例えばユーザA)が、自分のクライアントワークスペース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を実行したとき、Perforceがクライアントワークスペースの非作業状態のファイルを残らず削除し、もう一度同じファイルをした同じ場所にコピーしていることを知って驚きました。
Perforceでは、haveリストが各ファイルのクライアントルートに対する相対的な位置を記述し、各ファイルの物理的位置はPerforceコマンドが実行されるたびに計算されるだけなので、このようなことが起こります。つまり、Perforceは各ファイルが再配置されたと考え、p4 syncが実行されると、ファイルをそれまでの位置から削除して、新しい位置へコピーするのです。
ジョーがPerforceの働きを理解していれば、p4 flush #haveを実行していたでしょう。そうすれば、実際にはどのファイルもコピーされることなく、クライアントワークスペースのhaveリストは、ファイルの“新しい”位置を反映するように更新されたはずです。