「Perforceユーザー向けGit」のドキュメントは多数ありますが、その反対はほとんどありません。

私は以前Gitを使用したことがありましたが、最近、Perforceを頻繁に使用する必要がある仕事を始めました。私がGitで使用していた概念は、Perforceにまったく対応していないようです。

Gitに慣れている人のために、Perforceを使用するためのいくつかのヒントをまとめることに興味がある人はいますか？

これは私が過去数週間にわたって取り組んできたものです。それはまだ進化していますが、役に立つかもしれません。私はPERFORCEの従業員です。

GitユーザーのためのPerforceの紹介

GitからPerforceに、またはPerforceからGitに移動するのは簡単なことではないと言うのは、控えめな言い方です。表面上は同じことを行う2つのツールであるため、彼らのアプローチはこれ以上に異なることはありません。この短い記事は、Gitから来た新しいPERFORCEユーザーが彼らがいる新しい世界を理解するのを助けることを試みます。

飛び込む前に、少し回り道をしました。Gitを好む場合は、PerforceでGitを使用できます。Perforceサーバーとの同期を維持するGitリポジトリを生成するGit Fusionというツールを提供しています。GitとPERFORCEの人々は、同じコードで作業して調和して生活できます。ほとんどの場合、同僚のバージョン管理の選択に影響されません。Git Fusions 13.3は、Perforce Webサイトから入手できます。PERFORCE管理者がインストールする必要がありますが、インストールすると、そのリポジトリスライス機能がGitユーザーとして非常に便利になる場合があります。

管理者がGit Fusionをインストールするように説得できない場合は、Git自体にGit-P4と呼ばれるPerforceバインディングが付属しており、Gitを使用してPerforceワークスペースでファイルを変更および送信できます。その詳細については、https：//git.wiki.kernel.org/index.php/GitP4を参照してください。

まだここ？いいでしょう、Perforceを見てみましょう。

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

詳細に入る前に、GitとPerforceのいくつかの用語の違いについて簡単に説明する必要があります。

最初はチェックアウトです。Gitでは、これは、特定のブランチから作業領域にコードのコピーを取得する方法です。PERFORCEでは、これをコマンドラインまたはGUI P4Vの「最新のリビジョンを取得」から同期と呼びます。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がここ数年もビジネスを続けている理由は、ワークスペースが開発者にとって数百万のファイルプロジェクトを削減すると同時に、ビルドとリリースですべてのソースを簡単にまとめることができる素晴らしい方法であることです。 1つの信頼できる情報源。ワークスペースは、PERFORCEが同様にスケーリングできる主な理由の1つです。

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

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

PERFORCEワークスペースの全機能の詳細については、P4の構成をお読みください。

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

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

良いニュースは、そのように選択した場合、PerforceでGitスタイルのワークフローを使用できることです。Perforceでは、ワークスペースに「allwrite」オプションを設定できます。これは、すべてのファイルが書き込み可能なビットセットでディスクに書き込まれる必要があることをPERFORCEに伝えます。その後、Perforceに明示的に指示することなく、必要なファイルを変更できます。行った変更をPerforceで調整するには、「p4 status」を実行します。必要に応じて、追加、編集、削除するファイルを開きます。この方法で作業する場合、「p4 sync」の代わりに「p4 update」を使用して、サーバーから新しいリビジョンを取得する必要があります。「p4 update」は同期の前に変更をチェックするため、「p4 status」をまだ実行していない場合は、ローカルの変更が破棄されません。

明示的にチェックアウトする理由

私がよく受ける質問は、「なぜ明示的なチェックアウトを使用したいのか」というものです。最初は面白くないかもしれませんが、明示的なチェックアウトには強力な利点があります。

明示的なチェックアウトを使用する理由の1つは、コンテンツの変更についてファイルをスキャンする必要がなくなることです。小さなプロジェクトでは、各ファイルのハッシュを計算して違いを見つけるのはかなり簡単ですが、多くのユーザーはワークスペースに数百万のファイルを持っているか、サイズが100メガバイトではないにしても数百メガバイトのファイルを持っています。これらの場合のすべてのハッシュの計算は、非常に時間がかかります。明示的なチェックアウトにより、PERFORCEはどのファイルを操作する必要があるかを正確に知ることができます。この動作は、ゲーム、映画、ハードウェア業界などの大規模ファイル業界でPERFORCEが非常に人気がある理由の1つです。

別の利点は、明示的なチェックアウトが非同期通信の形式を提供することです。これにより、開発者は一般的にピアが何に取り組んでいるか、少なくともどこで作業しているかを知ることができます。不必要な競合を避けるために特定の領域での作業を回避したい場合があること、またはチームの新しい開発者がおそらく必要のないコードに迷い込んだことを警告することができます編集する。私の個人的な経験では、Gitで作業するか、Perforceを使用して、自分が唯一の寄稿者または寄稿頻度の低いプロジェクトでallwriteを使用する傾向があり、チームと緊密に作業している場合は明示的にチェックアウトします。ありがたいことに、選択はあなた次第です。

明示的なチェックアウトは、保留中のチェンジリストというPERFORCEの概念ともうまく機能します。保留中のチェンジリストは、開いているファイルを入れて作業を整理できるバケットです。Gitでは、作業を整理するためのバケットとしてさまざまなブランチを使用する可能性があります。ブランチはすばらしいですが、実際にサーバーに送信する前に、作業を複数の名前付き変更に編成できると便利な場合があります。複数のブランチまたは複数のプロジェクトを1つのワークスペースにマッピングする可能性があるPERFORCEモデルでは、保留中の変更リストにより、個別の変更を簡単に整理しておくことができます。

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

Git機能のPerforceの代替

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

切断された作業

PERFORCEバージョン管理サービスから切断された状態で作業するための2つのオプションがあります（これは、PERFORCEサーバーの高級用語です）。

1）P4Sandboxを使用して完全なローカルバージョン管理とローカル分岐を実行する

2）必要に応じてファイルを編集し、「p4ステータス」を使用して、Perforceに何をしたかを伝えます

上記の両方のオプションを使用すると、ファイルのロックを解除する必要がないように、ワークスペースで「allwrite」設定を使用することを選択できます。このモードで作業する場合、「p4 sync」の代わりに「p4 update」コマンドを使用して新しいファイルを同期する必要があります。「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での作業に必要な基本的なコマンドを確認します。

gitとp4の最大の違いは、既存の回答では対応していないが、抽象化の単位が異なることです。

• gitでは、抽象化はパッチです（別名diff、別名チェンジセット）。gitのコミットは、基本的に、コミットされるdiffファイルの以前の状態と現在の状態の間で実行される出力です。
• PERFORCEでは、抽象化はファイルです。p4のコミットは、その時点でのコミットのファイルの完全な内容です。これはチェンジリストにまとめられていますが、リビジョン自体はファイルごとに保存され、チェンジリストは単にファイルの異なるリビジョンをまとめて収集します。

他のすべてはこの違いから生じます。gitの抽象化の観点から見ると、一連のパッチを順番に適用することですべてのファイルを完全に再構築できるため、gitでの分岐とマージは簡単です。したがって、2つのブランチをマージするには、ソースブランチにすべてのパッチを適用するだけで済みます。正しい順序でターゲットブランチからターゲットブランチに存在しない（両方のブランチに重複するパッチがない場合）。

PERFORCEのブランチは異なります。PERFORCEのブランチ操作は、ファイルをあるサブフォルダから別のサブフォルダにコピーし、サーバー間のメタデータでファイル間のリンクをマークします。（別のブランチからのファイルをマージするにはintegrationPERFORCEの用語で）、PERFORCEは見ていきます完全なコンテンツソースの枝と上の「頭」でファイルの完全なコンテンツターゲットブランチの先頭にファイルのと必要に応じて、共通の祖先を使用してマージします。git canのようにパッチを1つずつ適用することはできません。つまり、手動マージがより頻繁に行われます（そして、より苦痛になる傾向があります）。

PERFORCEは（CVSやSubversionなどに近い）かなり伝統的なリビジョン管理システムであり、通常、最新の分散リビジョン管理システムほど複雑ではないと考えられているため、おそらくそのようなドキュメントは多くありません。

あるコマンドから別のコマンドにマップしようとするのは適切な方法ではありません。集中型と分散型のリビジョン管理システムの概念は同じではありません。代わりに、Perforceの典型的なワークフローについて説明します。

1. p4 edit編集するファイルごとに実行します。どのファイルを編集しているかをPerforceに伝える必要があります。新しいファイルを追加する場合は、を使用しますp4 add。ファイルを削除する場合は、を使用しますp4 delete。
2. コードを変更します。
3. 実行p4 changeして変更セットを作成します。ここでは、変更の説明を作成し、オプションで変更セットからファイルを追加または削除することもできます。p4 change CHANGE_NUMBER必要に応じて、後で実行して説明を編集できます。
4. 必要に応じて、コードをさらに変更できます。他のファイルを追加/編集/削除する必要がある場合は、を使用できますp4 {add,edit,delete} -c CHANGE_NUMBER FILE。
5. p4 syncサーバーから最新の変更を取り込むために実行します。
6. 実行p4 resolveして、同期による競合を解決します。
7. 変更を送信する準備ができたら、を実行しp4 submit -c CHANGE_NUMBERます。

を使用p4 revertして、ファイルへの変更を元に戻すことができます。

ファイルが重複しない限り、複数のチェンジセットで同時に作業することができます。（Perforceクライアントのファイルは、一度に1つのチェンジセットでのみ開くことができます。）これは、小さな独立した変更がある場合に便利です。

別のチェンジセットですでに開いているファイルを編集する必要がある場合は、別のPERFORCEクライアントを作成するか、後でから既存のチェンジセットを隠しておくことができますp4 shelve。（とは異なりgit stash、シェルビングではローカルツリーのファイルは元に戻されないため、個別に元に戻す必要があります。）