Perforce の利点は何ですか?
Perforce が特定の状況で、たとえば Subversion よりもどのようにうまく機能するかについて、いくつかの洞察を得たいと思っています。
Perforce と Subversion の両方の経験があり、利点があるとは思わない場合、または svn には Perforce よりも利点があると考えている場合は、その理由も知りたいです。
Perforce の利点は何ですか?
Perforce が特定の状況で、たとえば Subversion よりもどのようにうまく機能するかについて、いくつかの洞察を得たいと思っています。
Perforce と Subversion の両方の経験があり、利点があるとは思わない場合、または svn には Perforce よりも利点があると考えている場合は、その理由も知りたいです。
私は Perforce だけでなく、Clearcase、Sourcesafe、RCS、PVCS、CVS、および Subversion を何年も使用してきました。最近では、GIT も使い始めました。
この経験から、ほとんどの目的において、Perforce は商用環境に最適なバージョン管理システムであるというのが私の意見です。最初は Subversion ほど単純ではありませんが、特に分岐とマージに関する多くの強力な機能を備えています。通常、この環境には「デフォルトでロック」する方法が適しています。
個人的なもの、小規模な共同プロジェクト、小規模なスタートアップ、またはオープン ソース プロジェクトの場合、多くの場合、Subversion の方が適していると思います。彼らは異なるアプローチ、異なる働き方をしています。それらを単純に並べて、どれが最適かを言うことはできません。
そうは言っても、私は ClearCase が嫌いです。通常、ClearCase は上から強制的に下げられます (つまり、管理上の決定)。
Subversion が Perforce に勝る多くの場合、最近では多くの人が GIT、Bazaar、Mercurial などの分散システムを好むようです。私がGITについて見てきたことから、彼らは正しいかもしれませんし、他のポスターがそれを支持すると確信しています.
Perforce の大きなセールス ポイントの 1 つは速度です。サーバーは、クライアント上のファイルの状態を追跡します。したがって、「デポの最新の状態を取得する」などの操作は簡単です。サーバーは、ユーザーが持っているファイルを既に認識しており、最小限の情報をユーザーに送り返すことができます。
この利点は、最初にファイルをチェックアウトせずにローカルで編集したり、統合を実行せずにローカルでファイルを移動したり、ファイルをローカルで削除したりすると、サーバーとクライアントが同期しなくなる可能性があるという欠点ももたらします。
Perforce サーバーは最小限のデータのみをクライアントに送信するため、Perforce は、米国のクライアントがロンドンのデポにアクセスする状況など、低速リンクでも適切に機能します。そうは言っても、Perforce プロトコルは比較的「おしゃべり」であるため、輻輳したリンクで速度が低下する可能性があります。
私は毎日仕事で perforce を使用していますが、誰にもお勧めしません。おそらく何年もの間最高の SCMだったと思いますが、そのコア モデルは時代遅れです。
Perforce は、おそらく私が今まで使用した中で最も集中化された SCM システムです。あなたのディスクに何もキャッシュしていないことを彼らが誇りに思っていると想像してみてください。多くの場合、強制同期を行わない限り何もしないため、同期を行うのは煩わしいです - そして強制同期はサーバーからすべてをあなたにコピーします - プロジェクトが10GBの場合、それらすべてをコピーします.
SourceSafe、CVS、SVN、Mercurial、および git を使用した経験があります (最後の 2 つより少ない)。
ほとんどのオープンソース SCM は成熟しており、そのうちの 1 つを選択できると思います。集中型が必要な場合は SVN を使用し、分散型が必要な場合は Mercurial を使用します (Windows で git を使用した経験はありません)。
私がperforceで抱えていた他のいくつかの問題:
Perforce は、たとえば svn とは少し異なるモデルを持っています。すべてのファイルは作業コピーで常にロックされており、編集を開始することを宣言する必要があります。これには、たとえば、他の誰がファイルで作業しているかをいつでもすぐに確認できるという利点があります。
全体として、他の SCM との違いはそれほど大きくありません。多くの場所で Perforce に遭遇します。なぜなら、Perforce は、Windows と Mac で動作する数少ない (唯一ではないにしても) 部分的に適切な SCM の 1 つだったからです。
確かクライアント数限定で無料で使えるので、苦労せずに試してみたい…。
個人的には、perforce を軽蔑します。そのユーザー インターフェイスは恐ろしく、複雑で、直感的ではありません。バグが多く、頻繁にクラッシュします。
以前に (Tortoise SVN 経由で) SVN を使用したことがあり、はるかにシンプルで使いやすいことがわかりました。
もちろん、これはすべてユーザーの視点からのものであり、おそらく SCM は別の視点を持っています。
「 Subversion の代わりに Perforce を使用する利点は何ですか?」にヒントがあるかもしれません。(Perforceタグに従うだけです...)。
私たちは職場で Perforce を使用しています。さまざまな SCM ソフトウェアの経験はほとんどありませんが、これは非常によくできていて、優れた GUI (Windows 上)、優れたコマンド ライン サポート、多くの優れた機能を備えていると思います。そのロジックに慣れる必要がありますが、おそらくほとんどの SCM に当てはまると思います。
Perforce はロックをサポートしており、マージできない一部のファイル タイプ (バイナリ リソース、イメージなど) ではロックが必要なようです。ただし、通常のソース ファイルをロックする必要はありません。これらのファイルは、複数のユーザーが同時に編集するために開いてから、デポにマージして戻すことができます。
Perforceのシステムには「チェンジリスト」があり、変更を複数のファイルにグループ化し、それらを1つのユニットとして扱います。SVN でも似たようなことができると思いますが、そのままでは簡単ではありません。
私は以前の Yuval に同意します。Perforce と svn を GUI モードとコマンドライン モードの両方で使用してきたので、svn の方が好きです。しかし、私が当時働いていた会社は、使用していた無料の cvs から Perforce に切り替えました。その GUI は派手です。コミット モデルが異なると思います。ロックを使用しているため、一部の開発者や管理者にとっては好ましいかもしれません。商用環境では、バージョン管理ツールのサポート担当者がいることも役立つ場合があります。一部の大企業では、コードのすべての行のサポートを受けられるようにするために、実稼働環境でオープンソース コードを使用することが禁止されていると聞いています。
Perforce サーバーは、クライアント上の任意のファイルを読み書きできるため、任意のコードを実行できます。Perforce の構成はすべてサーバー側であるため、サーバーはクライアントのコンピューターのハード ディスク全体をリポジトリとして扱い、必要なことを何でも行うことができます。
SELinux サンドボックス以外で Perforce を実行しないでください。
注意: Perforce クライアントはサーバーの操り人形です。オペレーティング システムのセキュリティ機能を使用して、実行してほしくないことを実行しないようにする必要があります。常に Perforce クライアントを敵対的なものとして扱います。