大企業がPerforceを使用する理由
いくつかの大企業について聞いたことがあります。 Google、FacebookはPerforceを使用
SVN/GitがPerforceを置き換えることができない理由はありますか？
正当化はおそらく以前ほど重要ではありませんが、PerforceはSubversionよりも大きなリポジトリでより良いパフォーマンスを発揮する傾向があります。これが、マイクロソフトがソースデポを構築するためにPERFORCEにソースライセンスを取得した理由の1つです。 NTのリポジトリは怪物であり、商用またはその他の多くの製品がそれを処理することはできません。
また、少なくとも一度は、Perforceのビジュアルツールは、SubversionまたはGitで（いわば）箱から出して利用できるものよりもはるかに優れていました。 Meldを使用している場合、おそらくそれらのことは以前よりも重要ではありませんが、分岐とマージの視覚化を含め、Perforceが非常にうまく行ったいくつかのことがまだありますが、詳細な記憶はありません私が最後にパーフォースに触れてから約3年は、たとえばGithubのアプローチよりも洗練されているように見えました。
Perforceを使用すると、実際にその利点が何であるかを理解できます。彼らは長い間、無料の2ユーザーサーバーオプションを提供してきました。経験のあるソースコード管理システムによっては、チームがしばらくテストした後で、アップグレードのコストに見合う価値があるかもしれません。小規模な店舗の場合、これに加えて、これを使用して気に入った開発者のネットワーク効果が、Perforceが有料ユーザーを獲得する理由です。 Dmitriの皮肉な発言とは対照的に、小規模な開発チームを持つ企業でPerforceを販売するためのCTOの獲得と食事はそれほど多くありませんが、そのような場所で使用されています。
私がマイクロソフト以外で取り組んだプロジェクトのほとんどは、Git、Mercurial、またはSubversionによって十分にサービスを受けることができます。私がこれまでに取り組んできた企業の大半は、これらのオプションの1つを使用しています。しかし、スイートスポットがあります。通常、リポジトリのサイズ、分岐とマージのモデル、およびチームの経験と歴史を組み合わせて、人々が商用ツールを使用するように導きます。たとえば、大規模なGitリポジトリはめったに見ません。これは、Gitの本質的な制限によるものではない可能性があります。私はそれを完全に無知であることを認めます。ただし、一部のプロジェクト（Windows NTなど）では、無料のソリューションに実用的な制限がある場合があります。
私はsvn、git、およびPERFORCEについて、ユーザーとしても、サーバーのセットアップおよび保守においても、ある程度熟練しています。
会社、または私のような孤独なプログラマーにとっても、ソース管理は、コードの開発と販売を行っている実際の収益化活動をサポートするために発生するコストです。したがって、考慮すべき要素がいくつかあります。
- それはあなたの開発モデルにどの程度うまく適合しますか？
- 開発者が学び、使用するのはどれくらい簡単ですか？
- 開発者にとって日常的な操作は高速ですか？
- それを使用するプロセスは、コードを書くという本当の仕事の邪魔になりますか？
- セットアップとメンテナンスは簡単ですか？
- 購入して維持するにはいくらかかりますか？
- ヘルプが必要な場合、簡単に入手できますか？
個々のシステムの長所と短所に関する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を使用できないためです。 」 「もちろん、gitでそれを行うことができます。」 "どうやって？" 「そうですね、最初にbashスクリプトを書く必要があります...」「気にしないで」
そして、多くの履歴を持つソースツリーを最初に作成するのに時間がかかります。 Perforceを使用すると、履歴がサーバー上に保持されるため、すべてのファイルの最新バージョンを取得できるので、非常に高速です。前述の9 GBのツリー全体を設定する場合でも、VPN経由で数時間しかかかりませんでした。 gitを使用すると、長い時間と永遠の間にどこかにかかる可能性があります。 GTK +またはXサーバーのgitリポジトリを複製する必要がある場合があります。それは長い昼休み、またはおそらく就寝の時間です。
本当に、それは仕事に適したツールの問題です。 svnは、アップルのオープンソースの取り組みのほとんどで問題なく機能し、カーネルハッキングにはひどいものになります。 gitはGTK +ではうまく機能しますが、WebKit内での作業は信じられないほど遅くなります-ソースツリーと履歴が大きすぎる（WebKitのsvn-to-gitポータルからのコードを扱う難しい方法を見つけたため）。巨大なソースツリーがあり、集中管理が必要な場合は、Perforceが適切に機能します。それぞれが適切なコンテキストで正常に動作します。
特にGIT、およびSVNはある程度古いものではありません。90年代半ばに確実なバージョン管理が必要な場合は、SVNがまだ初期段階にあり、CVSがCVSだったため、ほとんど商用化する必要がありました。システムに多くの投資をすると、システムを移動するのは困難になります。
ああ、そしてこれらの決定を下す人たちは、おそらくバージョン管理システムと対話することはないでしょうが、前述の営業スタッフによってうんざりして食事をします。
私は今、ほぼ9年間ゲーム業界のプログラマーであり、これまでに取り組んだすべてのプロジェクトで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のファンボイだと思う前に、最後に私が企業にPERFORCEを勧めたのは7年以上前です。 PERFORCEのライセンスあたりのコストは800ドルです。これはClearCaseと比較すると安価ですが、Subversionと比較するとかなり高価です。 SubversionよりもPerforceを正当化するのに苦労しています。
さらに、ほとんどの開発者はSubversionを使用しています。彼らは、Subversionとは異なる動作方法を持つPerforceを学びたくありません。 Perforceでは、clientを作成する必要があり、ファイルを変更する前に編集用にマークを付ける必要があります。 Subversionでこれを行う必要はありません。
SubversionよりもPerforceとの統合も少なくなっています。その一部はclientの使用によるものです。 VisualStudioやHudsonでもうまく機能しません。その一部は、Perforceがクライアント統合を作成する必要があるという事実によるものです。
専有ライセンスには管理コストと呼ばれるコストがあります。ユーザーあたり$ 1.00でソフトウェアをライセンスできるとしたらどうでしょう。一体、それを2ビットにします。数千のライセンスで250ドルしかかかりません。
今、あなたはライセンスを管理するフルタイムの人が必要です。平均的な技術労働者は、会社に約2年間滞在します。つまり、毎年500人が退職し、さらに500人が来るということです。毎週10人ずつ、ライセンスを変更する必要があります。次に、プロジェクトが有効になり、さらに250ライセンスが必要になる場合があります。これらは、注文、入力、および保守する必要があります。それには数週間かかることがあります。
これが、多くの企業がオープンソースに移行した理由です。ライセンスの費用ではありません。あなたは開発者に年間$ 150,000を支払いますが、Perforceライセンスの別の$ 800は何ですか？そのライセンスを管理しています。 Perforceは、ClearCaseと比較すると見栄えがよく、より速く、より簡単で、より安く、より優れています。しかし、Subversionに反対ですか？ PERFORCEはより高速で、おそらくより良いかもしれませんが、それは800ドル良いのでしょうか？ライセンスをより適切に管理していますか？それは望ましいツールをよりよく使用していませんか？
そのため、PERFORCEで問題が発生する可能性があります。
Gitは、万能ツールではありません。誰がリポジトリにアクセスできるかを一元管理したくない場合に最適です。しかし、それは多くの状況で苦痛になる可能性があります。私がそれを置く方法はこの方法です：
- オープンソースプロジェクトを実行します。万人があなたのリポジトリ全体のコピーを持っているとしたら、あなたは幸せですか、それとも腹を立てますか？
- 独自のソフトウェアを使用して競合他社に優位性をもたらす金融取引デスクを運営しています。万人があなたのリポジトリ全体のコピーを持っているとしたら、あなたは幸せですか、それとも腹を立てますか？
一元化されたビルドを行う場合は、とにかく全員が単一のリポジトリを使用する必要があります。この状況での分散システムの利点は何ですか？実際、それは人々に働きかけることを奨励することができますオフライン。開発者は単に自分の陽気な方法で出発し、最後の分まで何もコミットしないかもしれません。次に、すべてを再び機能させるために必死に2日を費やします。
私はGitに反対ではありません。多くの場合、私はGitを推奨しています。これには、相互の接続が不十分な分散チームや、ソースリポジトリにアクセスできるすべてのユーザーを追跡したくない場所が含まれます。
たとえば、大学のコンピュータサイエンス部門では、生徒がソース管理を使用できるようにして、教師が見られるようにコードを配置したいと考えていました。いい案。標準的なビルドと開発の手順を理解せずに大学を離れる子供が多すぎます。 Gitをお勧めします。
Gitを使用することにより、リポジトリの管理者は、他の教授からコミットを取得するだけで済みます。彼らは個々の学生について心配する必要はありません。教授は学生がリポジトリのバージョンにコミットすることを許可できます。学生はグループで作業でき、各グループはリポジトリのバージョンを共有できます。
大学がSubversionを使用している場合、誰かがすべての学生を知っていて、中央リポジトリへのすべてのアクセスを彼らに与える必要があります。誰が何をどこでチェックインできるかを管理する必要があります。教授がグループプロジェクトを割り当てた場合は、それをセットアップして管理する必要があります。あなたはそれを管理するためだけにフルタイムの人を必要とするでしょう。
これは、あるチームが他のチームよりも優れているサッカーゲームではありません。ツールはさまざまな方法で機能し、それぞれに長所と短所があります。 PERFORCEは優れたツールです。残念ながら、推奨するのが難しい状況が発生しています。
Gitは素晴らしいですが、私は自分の個人的なソースリポジトリのためにSubversionにフォールバックしています。結局、私はそれを共有しません。Subversionの方が使いやすいだけです。インターネット上でリポジトリを常時稼働させる必要がないため、小規模なチームの場合は個人的な作業にGitを使用します。ほとんどの商用サイトでは、Subversionが最適に機能することがわかります。しかし、Gitが輝く状況があります。
PERFORCEのようなツールにはワインを販売する人がいて、購入を担当する人に食事をしますが、Gitにはありません。もちろん、それは私が話すのは皮肉な側面ですが、プロセスを間近に見ることによってもたらされる皮肉です。
完全に明確にするために：I しないでくださいは、CIOが廊下で酔っ払っているのを見るたびに、次の四半期に新しいバージョン管理システムを使用することを期待しています。多くの組織では、使用と取得の間に断絶があるだけです。もちろん、企業がPerforceを使用する理由は他にもあります。たとえば、ワークフローへの実装にすでに多額の投資をしている可能性があります。しかし、一般に---そしてこの質問は非常に一般的です--- FOSSツールを使用しないことには機能上の利点はありません。
「ワインとダイニング」の贈収賄がまだ適用可能かどうかはわかりませんが、ほとんどのマネージャーは、製品を見つけることにしたときに、さまざまな出版物（経営者向け）を読み、製品の賞賛を集めたパンフレットやパンフレットを調べます。美徳。
FOSS製品はそれらの場所では機能しません！
したがって、ほとんどの管理購入の決定は、広告とマーケティングに基づいて行われます。彼らは評価を行うかもしれませんが、そのような製品のいくつかの評価を行います。
もう1つの理由は、成熟度によるものです。現在使用している製品の中には、真剣なビジネスでの使用に十分なほど安定していないもの、サポートオプションがないもの、ビジネスソリューションとしての実績がないものがあります。これらは考慮すべき重要な事項であり（技術者として、FOSSソリューションを使用して失敗するリスクがビジネスの運営を維持するために最小限であれば、私は喜んでFOSSソリューションを評価します）、一部のマネージャーはそれらを持ち歩かないことに注意を払います。彼らは上司に責任があり、製品の背後にサポート組織があれば、はるかに快適になります。
最後に、多くのFOSS製品はその背後にサポートを提供していますが（SVNの場合はCollabnetまたはWandiscoを考えてください）、それでも「裏口のオタクが作った」という評判を得ています。それは一般的にb * * ** tであり、最高のFOSSは商用製品と非常によく競合しますが、私のマネージャーはまだ確信する必要があります。たぶん、彼は未熟なFOSS製品と成熟したFOSS製品の違いを理解していないだけかもしれません。多分彼は気にしない。
とにかく、PERFORCEはすばらしいSCMです。それを選択しない理由はありません。他のSCMについても同じことが言えますが、ここでも、他のSCMについては悪いことしか言えず、特定のいくつかの製品に関しては悪夢があります。
おそらく、私の会社が多くのオープンソースソフトウェアの使用を拒否しているのと同じ理由です（私が同意しているわけではありません）。
何かがうまくいかないとき、彼らは彼らが彼らが電話して、怒鳴ることができる誰かを望んでいます。
すべての回答はP4を使用している大企業に関するものであり（GoogleがP4を使用した理由を回答しています）、GoogleがPerforceを引き続き使用している主な理由の1つは、Perforceではリポジトリのサブツリーをチェックアウトできるが、Gitではそれができないことです。 Googleのような大規模なソースリポジトリで大きな違いがありました。
そして私が聞いた限りでは、FacebookはSVNとGit-SVNを使用しています
SVNは、まあ、SVN、およびPERFORCE（ツールを比較したときの4年前）なので SVNよりもいくつかの点で優れています 。 （分岐はその1つだと思います。）
distributedのように、GITはDvcです。会社のチームにとっては、分散された部分は、気にも願いにもないものかもしれません。
大企業が大きくて扱いにくい、「エンタープライズ」バージョン管理システムを購入する傾向があるもう1つの理由：
IT部門の中上級管理者は、VCSをすべてのプロジェクトが使用するものと見なします。または、使用を強制することもできます。 VCSの使用を強制したら、そこに小さな「プロセス」も配置してみませんか？つまり、「企業全体」のシステムを指定する機会があり、それを集中管理して、「災害復旧」と「ワークフロー機能」を追加して、「CMMレベルStraightJacketだ」と言えるようにします。準拠！」 VCSは、ワークフローを強制する機能を配置するにはターゲットが簡単すぎるため、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は「ドアに足を踏み入れ」、そしてそれらは人々をそこから離れさせるのにまだ十分に混乱していないです。