175

「Git for Perforce users」のドキュメントはたくさんありますが、その反対のドキュメントはほとんどないようです。

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

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

4

3 に答える 3

335

これは、私が過去数週間にわたってオンとオフで取り組んできたことです。まだまだ発展途上ですが、お役に立てれば幸いです。私は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 のいくつかの用語の違いについて簡単に説明する必要があります。

最初はcheckoutです。Git では、これが特定のブランチから作業領域にコードのコピーを取得する方法です。Perforce では、これをコマンド ラインまたは GUI P4V の「Get Latest Revision」からの同期と呼びます。PERFORCE では、P4V またはコマンド ラインからのチェックアウトp4 editという単語を使用して、バージョン管理システムからファイルを変更する予定であることを意味します。このドキュメントの残りの部分では、Perforce の意味でチェックアウトを使用します。

2 つ目は、Git commitと Perforce submitの比較です。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 つにまとめてビルドおよびリリースすることを容易にしているからです。 1 つの信頼できる情報源。ワークスペースは、PERFORCE が拡張できる主な理由の 1 つです。

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

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

Perforce ワークスペースの全機能の詳細については、Configuring 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 つは、内容の変更のためにファイルをスキャンする必要がなくなることです。小規模なプロジェクトでは、違いを見つけるために各ファイルのハッシュを計算するのはかなり安価ですが、ユーザーの多くはワークスペースに数百万のファイルを持っているか、サイズが数百メガバイトのファイルを持っています。このような場合にすべてのハッシュを計算するには、非常に時間がかかります。明示的なチェックアウトにより、Perforce はどのファイルを操作する必要があるかを正確に知ることができます。この動作は、Perforce がゲーム、映画、ハードウェア業界などの大容量ファイル業界で非常に人気がある理由の 1 つです。

もう 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 つのオプションがあります。

1) P4Sandbox を使用して、完全なローカル バージョニングとローカル ブランチを実現する

2) 好きなようにファイルを編集し、'p4 status' を使用して 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 で作業するために必要な基本的なコマンドを確認します。

于 2013-06-26T22:04:03.667 に答える
20

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、シェルビングはローカル ツリー内のファイルを元に戻さないため、個別に元に戻す必要があります。)

于 2013-06-25T20:18:00.327 に答える