大企業がPerforceを使用する理由 [閉まっている]

Google、Facebook、Perforceなどの大企業について聞いたことがあります

SVN / GitがPerforceを置き換えることができない理由はありますか？

正当化はおそらく以前ほど関連性が低くなりますが、PerforceはSubversionよりも大規模なリポジトリでパフォーマンスが向上する傾向があります。これが、MicrosoftがSource Depotを構築するためにPerforceのソースライセンスを取得した理由の1つです。NTのリポジトリは怪物であり、商業用またはその他の多くの製品で処理することはできません。

また、少なくとも一度は、Perforceのビジュアルツールは、SubversionまたはGitですぐに使用できる（いわば）ものよりもはるかに優れていました。Meldを使用している場合、おそらくこれらのことは以前ほど重要ではありませんが、分岐とマージの視覚化など、Perforceが非常にうまく行ったことがいくつかあります。 Perforceに最後に触れてから約3年は、たとえばGithubのアプローチよりも洗練されているように見えました。

Perforceを使用すると、実際にその利点が何であるかを理解できます。彼らは長い間無料の2ユーザーサーバーオプションを提供してきました。どのソースコード管理システムを使用したかによっては、チームがしばらくテストした後にアップグレードする価値があるかもしれません。小規模な店舗では、これに加えて、それを使用して気に入った開発者のネットワーク効果が、Perforceが有料ユーザーを獲得する理由になります。Dmitriの皮肉な発言とは対照的に、小さな開発チームを持つ会社でPerforceを販売するためのCTOの獲得と食事はそれほど多くないでしょうが、それはそのような場所で使用されています。

私がマイクロソフト以外で取り組んできたプロジェクトのほとんどは、Git、Mercurial、またはSubversionによって十分に役立つことができます。しかし、スイートサイズがあります。通常は、リポジトリサイズ、分岐モデルとマージモデル、およびチームの経験/履歴を組み合わせて、人々が商用ツールを使用するようにします。たとえば、大規模なGitリポジトリを見たことはほとんどありません。これは、Gitの本質的な制限によるものではありません。私はそれについて完全に無知であることを認めます。ただし、一部のプロジェクト（Windows NTなど）では、無料のソリューションに実際的な制限がある場合があります。

私は、ユーザーとして、およびサーバーのセットアップと保守の両方で、svn、git、およびPerforceにかなり精通しています。

企業、または私のような孤独なプログラマーでさえ、ソース管理は、コードの開発と販売を行う実際の金makingけ活動を支援するために発生する費用です。そのため、考慮すべき要素がいくつかあります。

• 開発モデルにどの程度適合しますか？
• 開発者が学習して使用するのは簡単ですか？
• 開発者の日常業務は高速ですか？
• それを使用するプロセスは、コードを書くことである彼らの実際の仕事からの注意散漫ですか？
• セットアップと保守はどれくらい簡単ですか？
• 購入して維持するにはどれくらいの費用がかかりますか？
• ヘルプが必要な場合、簡単に入手できますか？

個々のシステムの長所と短所に関するtl：drの詳細は省略します。昨年フルタイムコンサルティングに戻ったときに、3つすべてを見直して、高品質のソフトウェアをクライアントに配信することで、できるだけ多くのお金を稼ぐことができるかどうかを判断しました。浮気。「FOSSは善であり、非FOSSは悪である」という政治的考察を方程式から外したとき、私はPerforceのライセンスを放棄しました。

そして、それが大企業もPerforceを選ぶ理由です。

コメントのtl：drの詳細に加えて、もう少し説明します。

svnへの対処は簡単です。Perforceと比較して、犬のように遅いです。私は携帯電話用の組み込みLinuxを製造する会社で働いていましたが、完全なソースは9 GBでした。彼らはPerforceを使用しました。コードを取得したら、通常、LANで最新のソースを更新するのに数秒かかりました。または、自宅からVPN接続で数分かかりました。svnを使用した場合、それぞれ数分と数時間でした。

git vs. Perforceはより複雑です。多くの企業は、アクセス制御を備えた中央リポジトリを使用し、そこで簡単にコミットし、他のことを困難にするビジネス上の理由があると感じています。そして、Perforceはそのモデルに完全に適合しています。ただし、gitはローカルブランチで作業することを人々に積極的に奨励しており、それを別の方法で動作させる方法はありません。開発者は完全にローカルブランチで作業することができ、中央リポジトリにコミットすることはありません。そのため、企業が従業員をそのように働かせたくない場合、Perforceの方が優れたオプションです。

いくつかのビジネスニーズのために、gitには他の問題もあります。私はgitを使用している会社で働いていましたが、この議論を何回聞いたのかわかりません。「[他のVCS]を使用したいと思っています。 」「もちろん、gitでそれを行うことができます。」"どうやって？" 「まあ、最初にbashスクリプトを書く必要がある...」「気にしないで」

そして、多くの歴史を持つソースツリーを最初に移入するのに時間がかかります。Perforceでは、履歴がサーバーに保持されるため、すべてのファイルの最新バージョンを取得するだけで、非常に高速です-前述の9 GBツリー全体のセットアップでさえ、VPNを介して数時間しかかかりませんでした。gitを使用すると、長い時間と永遠の間にかかることがあります。GTK +またはXサーバーgitリポジトリのクローンを作成しなければならないこともありますが、それは長い昼休み、または就寝時間です。

本当に、それは仕事にふさわしいツールの問題です。svnは、Appleのほとんどのオープンソースの取り組みで問題なく動作し、カーネルハッキングにはひどいでしょう。gitはGTK +でうまく機能しますが、WebKit内での作業は非常に遅くなります-ソースツリーと履歴が大きすぎます（WebKitのsvn-to-gitポータルのコードを扱う難しい方法を見つけたため）。巨大なソースツリーがあり、集中管理が必要な場合、Perforceはうまく機能します。それぞれが適切なコンテキストで正常に機能します。

特にGIT、およびある程度のSVNはそれほど古いものではありません.90年代半ばに安定したバージョン管理が必要になった場合、SVNはまだ初期段階であり、CVSもCVSであったため、ほとんど商用化する必要がありました。システムに多くの投資をした後、それを動かすことは負担になります。

ああ、そしてこれらの決定をする人たちはおそらくバージョン管理システムと対話することはないでしょうが、前述の営業スタッフにbyされて食事をとられます。

私はゲーム業界で9年近くプログラマーを務めており、これまで取り組んできたすべてのプロジェクトでPerforceを使用しています。その特定の業界でPerforceを使用し続けているものがいくつかあると思います。

• 人々は長い間Perforceを使用しており、Perforceに非常に満足しており、別のソリューションに切り替えることをためらっています。また、意思決定者は、3000万ドルのプロジェクトを、これまで使用したことのないソフトウェアの手に委ねることをためらう場合があります。
• 多くの企業/チームは、社内ツールにPerforceサポートを追加しています。これには、別のVCSをサポートするために更新するのにかなりの作業が必要になる場合があります。
• プログラマーは別のGit / Hg / SVNに簡単に切り替えられるかもしれませんが、ゲーム開発チームには、アーティスト、デザイナー、プロデューサーなどの技術的なメンバーがそれほど多くありません。新しいシステムに慣れるには時間がかかる場合があり、変更に対して非常に抵抗力があると確信しています。

たぶん、Perforceの方が優れているので、Perforceが好きなのでしょうか？

• Perforceは高速です。SubversionやGitよりもはるかに高速です。
• PerforceマージはSubversionやGitよりも優れています。Gitは実際にはマージを行わず、Subversionのバージョントラッキングは少なくとも1.5ではあまり良くありません。
• Perforceは優れた顧客サポートを提供しています。
• Perforceは、Subversionのリポジトリリビジョンと個々のファイルリビジョンを組み合わせます。Perforceでは、変更リストまたは個々のファイルリビジョンを介してリポジトリリビジョンを表示できます。
• Perforceは、複数の変更リストを使用してSubversionよりもはるかに優れた仕事をします。Subversionのチェンジリストはやや後付けであり、それを使用する人はほとんどいません。Perforceは組み込まれています。変更されたファイルをデフォルトの変更リストから移動しても、誤ってコミットされることはありません。
• Perforceでは、作業ディレクトリのレイアウトを指定できます。たとえば、標準ソースコードのディレクトリツリーがあり、一部の顧客がカスタムソースを持っている場合、カスタムツリーを標準ツリーに重ねることができます。チェックアウトするアイテムのみを指定することで、簡単にスパースチェックアウトを実行できます。

さて、私がPerforce Fanboiであると思う前に、Perforceを会社に推薦したのは7年以上前でした。Perforceのライセンスあたりのコストは800ドルです。ClearCaseと比較すると安価ですが、Subversionと比較するとかなり高価です。私はSubforceよりもPerforceを正当化するのに苦労しています。

さらに、ほとんどの開発者はSubversionを使用しています。彼らは、Subversionとは異なる働き方を持つPerforceを学びたくないのです。Perforceでは、クライアントを作成する必要があり、ファイルを変更する前に編集用にマークする必要があります。Subversionを使用する必要はありません。

Perforce over Subversionとの統合も少なくなります。その一部は、クライアントの使用によるものです。VisualStudioまたはHudsonでもうまく動作しません。その一部は、Perforceがクライアント統合を作成する必要があるという事実によるものです。

専有ライセンスには管理コストと呼ばれる費用がかかります。ユーザーごとに1ドルでソフトウェアのライセンスを取得できるとしたらどうでしょう。さて、2ビットにしましょう。数千のライセンスでたった250ドルしかかかりません。

ここで、ライセンスを管理するフルタイムの人が必要です。平均的な技術者は約2年間会社に滞在します。これは、毎年500人が退職し、さらに500人が来ることを意味します。毎週10人ずつ、ライセンスを変更する必要があります。その後、プロジェクトが成功し、さらに250ライセンスが必要になる場合があります。これらは注文、入力、および保守する必要があります。それには数週間かかることがあります。

それが多くの商業企業がオープンソースに移行した理由です。ライセンスの費用ではありません。開発者に年間150,000ドルを支払っていますが、Perforceライセンスの別の800ドルはいくらですか？そのライセンスを管理しています。ClearCaseと比較した場合、Perforceは素晴らしく見えます：より速く、より簡単に、より安く、より良く しかし、Subversionに対しては？Perforceはより高速で、おそらくより優れているかもしれませんが、800ドルの方が良いでしょうか？ライセンスの管理は改善されていますか？目的のツールをより適切に使用していませんか？

PERFORCEに問題があるのはそのためです。

Gitは万能ツールではありません。リポジトリへのアクセス権を持つユーザーを集中管理したくない場合に最適です。しかし、それは多くの状況で痛みになる可能性があります。私がそれを置く方法はこの方法です：

1. オープンソースプロジェクトを実行します。百万人がリポジトリ全体のコピーを持っていた場合、あなたは幸せまたは怒っていますか？
2. 独自のソフトウェアを使用して競合他社に優位に立つ金融取引デスクを運営しています。百万人がリポジトリ全体のコピーを持っていた場合、あなたは幸せまたは怒っていますか？

集中ビルドを行う場合は、とにかく誰もが単一のリポジトリを使用する必要があります。この状況での分散システムの利点は何ですか？実際、それは人々がオフラインで働くことを奨励することができます。開発者は単純に自分のやり方で出発して、最後の最後まで何もコミットしません。次に、すべてが再び機能するように2日間を費やします。

私はGitに反対ではありません。多くの場合、Gitを推奨しています。これには、相互接続が不十分な分散チームや、ソースリポジトリにアクセスできる全員を追跡したくない場所が含まれます。

たとえば、大学のコンピュータサイエンス部門では、生徒にソース管理を使用させ、教師が見られるようにコードをそこに配置したいと考えていました。いい案。標準的なビルドおよび開発手順を理解せずに大学を去る子供が多すぎます。Gitをお勧めします。

Gitを使用することで、リポジトリの管理者は同僚の教授からコミットを取得するだけで済みます。彼らは個々の学生を心配する必要はありません。教授は、学生がリポジトリのバージョンにコミットすることを許可できます。学生はグループで作業でき、各グループはリポジトリのバージョンを共有できます。

大学がSubversionを使用した場合、誰かがすべての学生を知り、中央リポジトリへのすべてのアクセス権を与える必要があります。誰が何をどこでチェックインできるかを管理する必要があります。教授がグループプロジェクトを割り当てた場合、それをセットアップして管理する必要があります。あなたはそれを管理するためにフルタイムの人が必要でしょう。

これは、あるチームが別のチームよりも優れているフットボールの試合ではありません。ツールはさまざまな方法で機能し、それぞれに長所と短所があります。Perforceは優れたツールです。残念ながら、推奨するのが難しい状況が発生しています。

Gitは素晴らしいですが、個人のソースリポジトリのためにSubversionに頼り続けています。結局のところ、私はそれを共有せず、Subversionは使いやすいだけです。小規模なチームの場合、個人の作業にGitを使用します。これは、インターネット上でリポジトリをフルタイムで維持する必要がないためです。ほとんどの商用サイトでは、Subversionが最適に機能することが依然としてわかっています。しかし、Gitが光る状況があります。

「ワインと食事」の贈収賄がまだ適用されるかどうかはわかりませんが、ほとんどのマネージャーは、製品を見つけることに決めたとき、さまざまな出版物（管理を対象としています）で読み上げ、製品を称賛するパンフレットやパンフレットを見るでしょう美徳。

推測してください、FOSS製品はそれらの場所では機能しません！

そのため、ほとんどの管理購入の決定は、広告とマーケティングに基づいていることはほぼ間違いありません。彼らは評価を実行するかもしれませんが、そのような製品のいくつかについてです。

もう1つの理由は、成熟度によるものです。現在使用している一部の製品は、深刻なビジネスでの使用に十分なほど最近安定しており、サポートオプションがなく、ビジネスソリューションとしての実績がないものもあります。これらは考慮すべき重要な事項です（技術者として、FOSSソリューションを使用して失敗するリスクがビジネスの運営を維持するために最小限であれば、私は喜んでFOSSソリューションを評価します）。彼らは上司に説明責任を負っており、製品の背後にサポート組織がある場合、はるかに快適に感じるでしょう-あなたは結局あなたのビジネスのために1つを持っています。

最後に、多くのFOSS製品はそれらの背後にサポートを持っていますが（CollabnetやSVNのWandiscoを考えてください）、それでも「オタクの奥の寝室で作られた」という評判を得ています。それは一般にb * * ** tであり、最高のFOSSは商用製品と非常によく競合しますが、私のマネージャーはまだ納得する必要があります。多分、彼は未熟なFOSS製品と成熟したFOSS製品の違いに気付いていないだけかもしれません。多分彼は気にしない。

とにかく、Perforceは素晴らしいSCMであり、選択しない理由はありません。他のSCMについても同じことが言えますが、ここでも、他のSCMについては悪いことしか言えず、特定のいくつかの製品に関してはまだ悪夢があります。

Perforceのようなツールにはワインの販売員がいて、購入を担当する人がいますが、Gitにはありません。もちろん、それは私が話しているシニカルな側面にすぎませんが、そのプロセスを間近で見ることによってもたらされる皮肉です。

完全に明確にするために：廊下でCIOがつまずくのを見るたびに、次の四半期に新しいバージョン管理システムを使用することを期待しているわけではありません。多くの組織では、使用と取得の間で接続が切断されているだけです。もちろん、企業がPerforceを使用する理由は他にもあります。たとえば、ワークフローでの実装にすでに多額の投資をしている可能性があります。しかし、一般的に-そしてこの質問は非常に一般的です--- FOSSツールを使用しないことによる機能的な利点はありません。

私の会社が多くのオープンソースソフトウェアの使用を拒否しているのと同じ理由でしょう（私は同意しません）：

何かがうまくいかないとき、彼らは電話して叫ぶことができる誰かを望んでいます。

すべての回答がP4を使用する大企業について語っています（そして、GoogleがP4を使用した理由を回答しています）が、GoogleがPerforceを使用し続ける主な理由の1つは、Perforceではレポジトリのサブツリーをチェックアウトできますが、Gitではそれを実行できないことです。Googleのような大規模なソースリポジトリにより、大きな違いが生じました。

そして私が聞いた限りでは、FacebookはSVNとGit-SVNを使用しています

SVNは、SVNであり、Perforce（ツールを比較する4年前から）はSVNよりも優れているためです。（分岐はその中の1つだと思います。）

そして、GITはのように、DVCSである分散します。企業チームにとって、分散された部分は、気にも気にもならないものかもしれません。

大企業が大きくて不安定な「エンタープライズ」バージョン管理システムを購入する傾向がある別の理由：

IT部門の中〜上級管理者は、VCSをすべてのプロジェクトが使用するものと見なしています。または、VCSの使用を強制することもできます。VCSの使用を強制したら、そこにも少し「プロセス」を入れてみませんか？つまり、「エンタープライズ全体」のシステムを指定し、中央管理下に置いて、「災害復旧」と「ワークフロー機能」を追加して、「We are CMM Level StraightJacket」と言うことができます。準拠！」。VCSは、ワークフローを強制する機能を配置するにはあまりにも簡単です。

いくつかの変なうんち、汚いソフトウェア（Serena Dimensions）の選択に関しては、バハマで数回の20代の女性セールススタッフがいるビキニゴルフは、ディレクターまたはVPにほぼ何でも説得できると言われています。

大企業には、何らかの集中型モデルが必要です。開発者の開発が完了すると、カスタマーサポートに引き渡されます。50-200の分散開発者レポジトリをくまなくてはならないとき、あなたは本当にサポートシューズになりたいですか？また、ビルドは中央レポに基づいて行われ、ビルドは常に、常に、常に追跡可能で、再現可能でなければなりません。愚かな特許侵害で初めて裁判にかけられたときにこれを学びます。

Gitはこのモデルではうまく機能しません。小規模な会社、またはVPNアクセスが不十分な会社がある場合は、それが本当に素晴らしいところです。

ほとんどの大企業がPerforceを使用する理由の1つは、IT部門に多くの知識があり、それに関連する問題をトラブルシューティングする長年の経験がある専門家が多いことです。

将来、企業はPerforceからGITに移行し始めるかもしれないと感じています...私が知っているほとんどの開発者はそれを好むようです!! また、Perforceが今後数年間でそれほど支配的ではない理由のさらなる証拠については、http：//whygitisbetterthanx.com/#git-is-fastをチェックしてください !!

しばらく前に、VCSのセット（RCS、CVS、ClearCase、Perforceが以前に使用されたことは確かですが、他にもある可能性があります）から、使用中の一意のシステムとしてPerforceに切り替えました。それは小さなプロジェクトではありませんでした。移行には1年以上かかりました。担当チーム（私はその一部ではありませんでした）がいくつかのVCSを評価し、少なくともgitとsvnが既に使用されているものと同様に検討されました。私が彼らの報告を覚えているように、彼らは必要な機能のないツールを除外し、次に考えました：

• 特にリモートサイトでの一般的な使用でのパフォーマンス

• リソース要件

• 労働習慣に必要な変更の重要性

• サポートの可用性とコスト

PERFORCEは全体的に非常に明確な勝者でした。gitは最初の点ではわずかに優れていましたが、他の点では不利でした。

むかしむかし、ではないので、ずっと前（IDEは、VIと呼ばれていたとき）、のみ無料（オープンソース）システムはCVS、RCSとSCCSました。

• これらのどれも名前が変更されるファイルにうまく対処できませんでした。
• マージを記録しなかったため、2つのブランチがアクティブに機能していた場合、1つのブランチで作業が完了するまでマージするのは非常に困難でした。
• 彼らは非常に大きなコードベースにうまくスケールしませんでした
• 彼らは、大規模なプロジェクトが望むレベルのアクセス制御とプロセス情報を提供しませんでした。

市販のソースコード管理システムがたくさんあり、それらのほとんどは単一のマシンベンダー（IBM、DEC、HPなど）によって提供され、ハードウェアでのみ実行されていました。

その後、いくつかの企業が、PerforceやClearCaseなどのクロスプラットフォームの商用ソースコード管理を販売すると発表しました。

ClearCaseはRPC上に構築されましたが、多くの小さなネットワークパケットが「ラウンドトリップ」されるため、ワイドエリアネットワーク（インターネットだけでは）でうまく機能しませんでした。愛。

したがって、まだ一般的に使用されている唯一の「古い」商用ソースコード管理システムはPerforceです。Perforceが使用され、ビルドシステムとバグ追跡システムに統合されると、企業が他の何かに移行する短期的なメリットはほとんどありません。

要約すると、他の選択肢があまりないときに、PERFORCEは「ドアに足を踏み入れる」ことができました。