質問

Perforceユーザー向けのGitのドキュメントはたくさんありますが、その逆はほとんどないようです。

以前はGitしか使ったことがなく、最近Perforceを使うことが多い仕事を始めたのですが、非常に混乱することが多いことに気づきました。Gitで慣れ親しんだコンセプトが、Perforceではまったく通用しないようなのです。

Gitに慣れている人のために、Perforceの使い方のコツをまとめてくれる人はいませんか？

どのように解決するのですか？

この数週間、時々取り組んでいることがあります。まだ発展途上ですが、お役に立てるかもしれません。なお、私はPerforceの社員です。

GitユーザーのためのPerforce入門

GitからPerforceへ、あるいはPerforceからGitへの移行は、自明ではないと言っても過言ではありません。表向きは同じことをする2つのツールですが、そのアプローチはこれ以上ないほど異なっています。この簡単な記事では、Gitから来た新しいPerforceユーザーが、自分たちがいる新しい世界を理解する手助けをしようと思います。

もしあなたがGitを好むなら、PerforceでGitをうまく使うことができます。Git Fusionというツールを使って、Perforceサーバーと同期したGitリポジトリを生成することができます。GitとPerforceのユーザーは、同じコードで作業していても、同僚のバージョン管理の選択にほとんど影響されることなく、共存することができるのです。Git Fusions 13.3は、以下のサイトから入手可能です。 パーフォースホームページ . Perforceの管理者がインストールする必要がありますが、インストールすれば、リポジトリのスライス機能がGitユーザーにとって非常に便利であることが分かるでしょう。

管理者に Git Fusion をインストールするように説得できない場合は、Git 自体に Git-P4 という Perforce バインディングが付属しており、Perforce ワークスペース内のファイルを Git で変更・投稿できるようになっています。詳細は以下を参照ください。 https://git.wiki.kernel.org/index.php/GitP4

まだですか？よかった、Perforceを見てみましょう。

整理すべきいくつかの用語の違い

詳細な説明に入る前に、Git と Perforce の用語の違いについて簡単に説明しておきます。

まず1つ目は チェックアウト . Git では、この方法で特定のブランチのコードのコピーを自分の作業領域に取り込みます。Perforce では、これを 同期 コマンドラインまたはGUIのP4V "Get Latest Revision"から実行することができます。Perforce では、次の単語を使用します。 チェックアウト P4Vから、または p4 edit をコマンドラインから実行すると、バージョン管理システムからファイルを変更する予定であることを意味します。このドキュメントの残りの部分では、Perforce の意味でのチェックアウトを使用することにします。

2つ目は、Git コミット 対Perforce サブミット . Gitでコミットするところを、Perforceではサブミットします。すべての操作は Perforce という共有のバージョン管理サービスに対して行われるので、Perforce にはそれに対応する git push . 同じように、私たちは pull 上記のsyncコマンドがファイルの取得を代行してくれます。後述するP4Sandboxを使用しない限り、Perforceには純粋なローカルサブミットの概念はありません。

Perforceのキーコンセプト

Perforceを単純化すると、デポとワークスペースの2つがポイントになると思います。Perforce のデポとは、Perforce サーバーに存在するファイルのリポジトリです。Perforce サーバーは任意の数のデポを持つことができ、各デポには任意の数のファイルを格納することができます。Perforce ユーザがデポとサーバを同じ意味で使っているのをよく見かけますが、これらは別のものです。Perforce のサイトでは、複数のサーバを選択することもできますが、ほとんどの場合、すべてのファイルが 1 つのサーバに格納されます。

Perforce のワークスペースまたはクライアントは、Perforce サーバー内の一連のファイルをユーザーのファイルシステム上の場所にマッピングするシステム内のオブジェクトです。各ユーザーは使用するマシンごとにワークスペースを持ち、同じマシンに複数のワークスペースを持つこともよくあります。ワークスペースの最も重要な部分は、ワークスペース・マッピングまたはビューです。

ワークスペースビューは、ローカルマシンにマッピングされるべきデポ内のファイル群を指定します。これは、サーバー上で利用可能なすべてのファイルを必要としない可能性が高いので、重要です。ワークスペース ビューを使用すると、必要なファイルだけを選択することができます。ワークスペースは、複数のデポからコンテンツをマップすることができますが、1つのサーバーからしかコンテンツをマップできないことに注意することが重要です。

この点でPerforceとGitを比較すると、Gitでは、興味のあるGitレポのセットを選んで使用します。各レポは通常、関連するファイルだけを含むようにタイトにスコープされています。この利点は、自分で設定する必要がないことです。気になるものを git clone して完了します。これは、1つか2つのリポジトリしか扱わない場合には、特に良いことです。Perforceでは、必要なコードの断片を選んで選択するのに少し時間がかかります。

多くの Perforce ショップでは、ワークスペース ビューを自動的に生成できるストリームを使用しているか、スクリプトまたはテンプレート ワークスペースを使用してビューを生成しています。また、ワークスペースを自分で生成することをユーザーに任せているところも少なくありません。1つのワークスペースに複数のモジュールをマッピングできる利点の1つは、1つのチェックインで複数のコードモジュールを簡単に変更できることです。Gitの強制的な分離は、より良いモジュール性をもたらします。ありがたいことに、Perforceは厳密なモジュール化もサポートしています。すべては、あなたがツールをどのように使うかの問題なのです。

なぜワークスペースなのか？

Gitから来た人は、ワークスペースというコンセプトが、その価値以上に面倒だと感じやすいと思うんだ。Gitのリポジトリをいくつかクローンすることに比べれば、これは間違いなく事実です。ワークスペースが優れているのは、Perforceが長年にわたってビジネスを続けている理由でもありますが、ワークスペースは開発者が数百万ファイルのプロジェクトを整理する素晴らしい方法であると同時に、ビルドやリリース時にすべてのソースを一つの信頼できるソースから簡単に取得できるようにするためです。ワークスペースは、Perforceがこれほどまでに拡張できる重要な理由の1つです。

ワークスペースは、デポ内のファイルのレイアウトとユーザーのマシン上のレイアウトを必要に応じて変えることができるという点でも優れています。多くの企業は、ビジネスユニットやプロジェクトごとにコンテンツを見つけやすいように、会社の組織を反映してデポを整理しています。しかし、ビルドシステムはこの階層を気にしません。ワークスペースでは、デポの階層を、彼らのツールにとって意味のある方法で再マップすることができるのです。また、非常に柔軟性に欠けるビルドシステムを使用している企業では、コードを非常に特殊な構成にする必要があり、人間にはまったくもって分かりにくいということもあります。ワークスペースを使用することで、ビルドツールが必要な構造を取得しながら、人間がナビゲート可能なソース階層を持つことができるようになります。

Perforce のワークスペースは、ユーザーが作業したいファイルのセットをマッピングするために使用されるだけでなく、ユーザーが同期した各ファイルのリビジョンを正確に追跡するためにもサーバーで使用されます。これにより、同期時に、どのファイルを更新する必要があるかを確認するためにファイルをスキャンすることなく、システムが正しいファイルセットをユーザーに送信することができます。大量のデータを扱う場合、これはかなりのパフォーマンス向上につながります。Perforce の管理者は、どの開発者がどのファイルを同期したかを簡単に追跡して記録することができるため、非常に厳格な監査ルールを持つ業界でも、この機能は非常に人気があります。

Perforce のワークスペースの詳細については、以下を参照してください。 P4を設定する .

明示的チェックアウトと暗黙的チェックアウトの比較

Git から Perforce に移行するユーザーにとって、最も大きな課題のひとつが明示的チェックアウトの概念です。ファイルを変更し、バージョン管理システムに自分が行ったことを探すように指示するという Git/SVN/CVS のワークフローに慣れている場合、非常につらい移行となる可能性があります。

いい知らせは、PerforceでもGitスタイルのワークフローで作業できることです。Perforceでは、ワークスペースに"allwrite"オプションを設定することができます。これにより、Perforce はすべてのファイルを書き込み可能なビットに設定した状態でディスクに書き込むようになります。これにより、Perforce に明示的に指示することなく、任意のファイルを変更することができます。Perforce に変更を反映させるには、"p4 status" を実行します。これにより、ファイルが開かれ、追加、編集、および削除が適切に行われます。この方法で作業する場合、サーバーから新しいリビジョンを取得するために "p4 sync" の代わりに "p4 update" を使用するとよいでしょう。"p4 update" は同期する前に変更をチェックするので、まだ "p4 status" を実行していない場合はローカルの変更点を潰すことはありません。

なぜExplicit Checkoutなのか？

よく受ける質問に「なぜ明示的なチェックアウトを使おうと思ったのですか？

明示的なチェックアウトを使用する理由の1つは、コンテンツの変更のためにファイルをスキャンする必要性がなくなることです。小規模なプロジェクトでは、各ファイルのハッシュを計算して差分を見つけることはかなり安価ですが、ユーザーの多くは、ワークスペース内に数百万のファイル、あるいは数百メガバイトのサイズのファイルを持っています。このような場合、すべてのハッシュを計算するのは非常に時間がかかります。明示的チェックアウトにより、Perforce は作業する必要のあるファイルを正確に把握することができます。この動作が、ゲーム、映画、ハードウェアなどの大容量ファイル産業でPerforceが人気を博している理由の1つです。

もうひとつの利点は、明示的チェックアウトが非同期コミュニケーションの一形態を提供し、開発者が仲間の作業内容や、少なくともその場所をおおむね知ることができることです。また、チーム内の新しい開発者が、編集する必要のないコードに入り込んでしまったという事実を知らせることもできます。私の個人的な経験では、自分が唯一の貢献者であるか、頻繁に貢献しないプロジェクトではGitかPerforceとallwriteのどちらかで作業し、チームで緊密に作業しているときは明示的にチェックアウトすることが多いようです。いずれにせよ、選択はあなた次第です。

明示的なチェックアウトは、Perforce の保留中のチェンジリストの概念ともうまく連動しています。保留中のチェンジリストは、作業内容を整理するために、開いているファイルを入れることができるバケットです。Git では、作業内容を整理するためのバケットとしてさまざまなブランチを使うことができます。ブランチはすばらしいものですが、実際にサーバーに送信する前に、複数の名前のついた変更に作業を整理しておくとよいこともあります。Perforce では、複数のブランチや複数のプロジェクトをひとつのワークスペースにマッピングすることができますが、保留中のチェンジリストを使えば、個別の変更を整理しておくことが簡単にできます。

Visual Studio や Eclipse などの IDE を使って開発する場合は、IDE 用の Perforce プラグインをインストールすることを強くお勧めします。ほとんどのIDEプラグインは、編集を開始すると自動的にファイルをチェックアウトしてくれるので、自分でチェックアウトする手間が省けます。

Perforce が Git に置き換えた機能

• git stash ==> p4 shelve
• git ローカルブランチ ==> Perforce シェルフまたはタスクブランチのいずれか
• git blame ==> p4 annotate または Perforceタイムラプスビュー GUIから

切断された状態での作業

Perforce バージョン管理サービス (Perforce サーバーの略称) から切断して作業するには、2 つのオプションがあります。

1) P4Sandbox を使用して、完全なローカルバージョン管理およびローカルブランチを行う。

2) 好きなようにファイルを編集し、'p4 status' を使って、行ったことを Perforce に伝える。

上記の両方のオプションで、ワークスペースの "allwrite" 設定を使用して、ファイルのロックを解除する必要がないようにすることができます。このモードで作業する場合、新しいファイルの同期には "p4 sync" の代わりに "p4 update" コマンドを使用することをお勧めします。

Perforce クイックスタート

以下の例は、すべてコマンドラインから行います。

1) Perforceへの接続を設定する

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

これらの設定は、シェルの設定ファイルに貼り付けることができます。 p4 set を使用して Windows や OS X に保存するか、Perforce の設定ファイルを使用します。

1) ワークスペースの作成

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) サーバーからファイルを取得する

cd /Users/matt/work
p4 sync

3) 作業したいファイルをチェックアウトして、それを修正する

p4 edit main/foo; 
echo cake >> main/foo

4) サーバーに送信する

p4 submit -d "A trivial edit"

5) 実行 p4 help simple をクリックすると、Perforce で作業するために必要な基本的なコマンドを確認することができます。