version-control - 1000 人以上の開発者組織にどのバージョン管理システムを使用しますか? なんで？

Question

そこには多くのSCMシステムがあります。開いているもの、閉じているもの、無料のもの、かなり高価なものがあります。いくつかのサイト (非常に遅いリンクの背後にあるもの) を持つ 3000 以上の開発者組織に使用するのはどれ(1 つだけ選択してください) ですか? あなたが選んだものを選んだ理由を説明してください。（「～だから」だけでなく、理由も教えてください。）

score 38 · Accepted Answer

このような大規模なインストールの場合、少なくとも次の主要な要件があります。データの安全性、成熟度、堅牢性、スケーラビリティ、価格（シートあたりのライセンスとオープンソースは、シートあたりの価格に関係なく常に大きな違いをもたらします）、管理の容易さ
転覆は大丈夫だと思います。
利用可能なサポートがあります（collabnet、clearvision、wandiscoなどから）。Subversionがあなたのタスクを処理できるかどうかを彼らに尋ねることができます。
subversionには、非常に成熟したデータベースバックエンド（FSFS）があります。それは絶対に堅実であり、1.5以降、パフォーマンスを低下させることなく、非常に多くのリビジョンを処理できます。リビジョンはファイルシステムに書き込まれます。したがって、Subversionリポジトリの信頼性は、ファイルシステム、OS、およびストレージシステムの品質に依存します。
これが、ファイルシステムとしてZFSを備えたSolaris10を推奨する理由です。ZFSには、実動システム用の非常に優れたファイルシステム機能があります。しかし何よりも、データ整合性チェックサムを提供します。したがって、Subversionリポジトリにこの量のソースコードがあると、サイレントハードドライブビットエラーまたはコントローラまたはケーブルビットエラーによるリポジトリの破損について心配する必要がなくなります。今では、ZFSは十分に成熟しているため、UFSまたはその他の代替として安全に使用できます。
ハードウェア要件についてはわかりません。コラブネットがアドバイスをくれるかもしれません。
しかし、本当に良いスタート（遅すぎることが判明した場合はNFSストレージまたはバックアップストレージとして使用できます-とにかくそれを確実にうまく利用できるでしょう）は、第2世代のサンパー、つまりSunFireX4540サーバーになります：次のことができます（すべて80.000ドルの素敵な4Uラックサーバー内（定価-これは交渉可能です））：48 TBのディスク容量！、8つのAMD Opteron CPUコア、64 GBのRAM、Solaris 10がプリインストールされ、3年間のプラチナSunからのソフトウェアとハードウェアのサポート。したがって、このサーバーの単なるハードウェアとサポートの価格は、3000人の開発者のシートあたり25ドルになります。
非常に優れたデータの安全性を確保するために、48台のハードドライブを次のようにパーティション分割できます。オペレーティングシステム用の3台のドライブ（3ウェイRAID-1ミラー）、3台のホットスペア（未使用、障害発生時のスタンバイ）他のドライブの）、subversionリポジトリ用の14個の3ウェイRAID 1ミラー（14 * 3 = 42ドライブ）のzfsプール。14 TBのZFSRAIDスペースを80％だけ埋めたい場合、これはリポジトリの実際に使用可能なディスクスペースの約10テビバイト、つまり開発者1人あたり平均3GBになります。
この構成の場合：10 TiB 3-way Raid-1ZFS冗長でチェックサムされたディスクスペースを備えたSunx4540サンパーのSubversion1.6は、非常に深刻なスタートになるはずです。
3000人以上の開発者にとって計算能力が十分でない場合は、サンパーのディスク容量を使用できるより強力なサーバーを購入できます。ディスクのパフォーマンスが遅すぎる場合は、高速のscsiドライブの膨大なアレイをコンピューティングサーバーに接続し、バックアップソリューションとしてサンパーを使用できます。
確かに、このSubversionサーバーの計画と展開に関して、collabnetからコンサルティングサービスを利用し、SunからハードウェアとSolarisオペレーティングシステムのプラチナサポートを利用することは理にかなっています。
編集（コメント＃1への回答）：分散チームの場合、マスタースレーブ構成の可能性があります：WebDAV-Proxy。各ローカルチームには、リポジトリを複製するスレーブサーバーがあります。開発者は、このスレーブからすべてのチェックアウトを取得します。チェックインは、スレーブからマスターに透過的に転送されます。このようにして、マスターは常に最新です。トラフィックの大部分はチェックアウトです。すべての開発者は、開発者がコミットするすべてのチェックインを取得します。したがって、チェックアウトトラフィックは、3000人の開発者のトラフィックの99.97％になるはずです。50人の開発者がいるローカルチームがある場合、チェックアウトトラフィックは98％削減されます。チェックインは問題にはならないはずです。誰かが新しいコードをどれだけ速く入力できるでしょうか。明らかに、小さなチームの場合、サンパーを購入することはありません。必要なのは、十分なハードドライブスペースを備えたボックスです（つまり、ホールリポジトリを10TB保持する場合）。データの損失は会社の終わりではないため、raid5構成にすることができます。Solarisも必要ありません。地元の人々がそれに慣れているなら、あなたはそれにLinuxを置くことができます。繰り返しますが、これが本当に健全な概念であるかどうかは、collabnetのようなコンサルタントに尋ねてください。これだけ多くの席があるので、一度の相談にお金を払うのは問題ではないはずです。彼らはすべてを設定することができます。Sunは、solarisがプリインストールされたボックスを提供します。あなたは太陽のサポートがあります。したがって、構成は今後数年間変更されないため、現場でソラリスの第一人者は必要ありません。この構成は、今後数年間は構成が変更されないため、現場にソラリスの第一人者が必要です。この構成は、今後数年間は構成が変更されないため、現場にソラリスの第一人者が必要です。この構成は、
- チームから本社への低速回線は、冗長なチェックアウトデータで詰まることはありません。
- ローカルチームのメンバーはすぐにチェックアウトを取得できます
- これにより、サンパーの負荷が大幅に軽減されます。つまり、この構成では、サンパーが負荷を処理できるかどうかをまったく心配する必要はありません。
- 帯域幅のコストを削減します
編集（M3000のリリース後）：非常識なデータ整合性をさらに対象としたはるかに極端なハードウェア構成は、 M3000サーバーとJ4500アレイの組み合わせです。
- J4500ストレージアレイは実質的にサンパーですが、サーバーに接続できるようにするCPUパワーと外部ストレージインターフェイスがありません。
- M3000サーバーは、ハイエンドのRAS機能を備えたミッドレンジ価格のSparc64サーバーです。ほとんどのデータパスやCPUレジスタもチェックサムされます。RAMはECCで保護されているだけでなく、IBM Chipkill機能と同等の機能を備えています。メモリのRAIDです。シングルビットエラーが検出および修正されるだけでなく、メモリチップ全体が故障する可能性があります。データが失われることなく完全に-RAIDアレイでハードドライブに障害が発生した場合と同様です。
- ZFSファイルシステムは、データがCPUから送信される前、またはCPUに送信された後、データに対してCPUベースのエラーチェックサムを実行するため、ストレージコントローラーとJ4500のケーブル接続の品質は重要ではありません。重要なのは、M3000 CPU、メモリ、メモリコントローラなどのビットエラー防止および検出機能です。
- 残念ながら、Sunが品質を向上させるために使用している高品質のメモリースティックは、4コア（8スレッド）の4GB Ram M3000 + 48 TB J4500の組み合わせがサンパーとほぼ同等になるほど高価ですが、インメモリキャッシュの目的でサーバーメモリを4GBから8、16、または32 GBに増やす場合、価格は急激に上昇します。ただし、分散チームのマスタースレーブ構成を使用する場合は、4GBの構成で十分かもしれません。
- この3000開発者リポジトリのソースコードとデータの整合性が管理者によって非常に高く評価されている場合、このハードウェアの組み合わせは検討する価値があります。次に、ローテーションバックアップソリューションとして2つ以上のサンパーを追加することも理にかなっています（ハードウェア障害から保護するために必要ではありませんが、管理者のミスから保護するため、または物理的な災害の場合のオフサイトバックアップのために）。
- これはSparcであり、x86ソリューションではないため、このプラットフォーム用の認定されたCollabnetSubversionバイナリが無料で利用できます。
Subversionの利点の1つは、優れたドキュメントでもあります。O'Reilly（Subversionを使用したバージョン管理）の優れた本があり、 PDFまたはHTMLバージョンとして無料で入手できます。
要約すると、Subversion 1.6 + Solaris 10+3-way-raid-1冗長およびチェックサムされたZFS+サンパー+ローカルチーム用のマスタースレーブサーバーレプリケーション+Sunサポート+collabnet/ clearvision / orcaware /KarlVogelコンサルテーション+すべての開発者向けの優れた無料のSubversionマニュアルを提供するソリューションが必要です
- 非常に高いデータ安全性（非常に多くのソースコードにとって非常に重要です-リポジトリを破壊したくない、ビットエラーが発生する、ハードドライブが失敗する！）すべてのバージョン/リビジョンを本当に確実に保持する1つのマスターデータリポジトリがあります：ソース管理システムの主な機能。
- 成熟度-Subversionは、多くの企業やオープンソースプロジェクトで使用されてきました。
- スケーラビリティ-マスター/スレーブレプリケーションでは、マスターサーバーの負荷の問題は発生しないはずです。チェックインの負荷はごくわずかです。チェックアウトはスレーブによって処理されます。
- 低速接続の背後にあるローカルチームに高遅延はありません（レプリケーションのため）
- 低価格： Subversionは無料（シートごとの料金なし）、優れた無料のドキュメント、3年間でシートあたり年間わずか8ドルのハードウェアとマスターサーバーのサポートコスト、スレーブ用の安価なLinuxボックス、コラブネット他また、マスタースレーブレプリケーションによる低帯域幅コスト。
- 管理のしやすさ：基本的にマスターサーバーの管理は不要：Subversionコンサルタントはすべてを展開できます。Sunのスタッフは、故障したハードドライブなどを交換します。スレーブは、Linuxボックス、またはローカルサイトで利用可能な管理スキルであれば何でもかまいません。優れたSubversionドキュメント。

score 21 · Accepted Answer

1000人以上の従業員を抱えるいくつかの会社で働いたことがありますが、概して、すべての会社がPERFORCEを使用していることがわかりました。

「他に何か使ってみませんか？SVN？Git？Mercurial？Darcs？」と聞いたところ、（これはすべての企業で同じです）と言ったのです。 Perforce、それはそれ、またはSourceSafe、またはCVSのいずれかでした-そして正直なところ、これらの3つの選択肢を考えると、私もPerforceを使用します。

「より困難な」バージョン管理システムが非常に多くの人々の注目を集めることは困難であり、ソフトウェアチームの大部分が互いに18フィート以内で作業している場合、DCVSの多くの利点はあまり有益ではありません。

Perforceには、開発者が使用するための多くのAPIフックがあり、集中型システムの場合、多くのchutzpahがあります。

これが最善の解決策だと言っているわけではありませんが、少なくとも、PERFORCEが機能している非常に大規模な企業を見たことがあります。

score 10 · Accepted Answer

GitはLinuxカーネル用に作成されました。これは、公開情報を見つけることができるこのような状況に最も近い例である可能性があります。

score 5 · Accepted Answer

私はgitと言いたいのですが、その規模の会社がすべてLinuxになるとは思いません（Windowsでのgitのサポートはまだダメです）。したがって、Linuxがgitの前に使用していたSCM、つまりBitKeeperを使用してください

score 5 · Accepted Answer

2015 年現在、最も重要な要素は分散バージョン管理システム (DVCS) を使用することです。DVCS を使用する主な利点は、ソースコード操作の煩わしさを軽減することで、多くのレベルでソースコードのコラボレーションを可能にすることです。これは、1000 人以上の開発者組織にとって特に重要です。

摩擦を減らす

個々の開発者のチェックインは、コラボレーションアクティビティから分離されています。軽量チェックインは、短時間スケールで独立した作業のクリーンなユニットを促進します (1 時間または 1 日あたりの多くのチェックイン)。システムが分散した組織で構築されているため、コラボレーションは通常は異なる時間スケール (毎日、毎週、毎月の他のユーザーと同期) で自然に処理されます。

Git を使用する

DVCS オプションのうち、Gitだけを使用して、 GitHubまたはBitbucketの優れたコミュニティを利用する必要があります。大規模な民間組織の場合、内部コミュニティと内部ソースコードホスティングが重要になる場合があります ( Atlassian Stashなどのプライベートホスティングシステムを販売しているベンダーが存在します)。

Git を使用する主な理由は、Git が最も人気のある DVCS であることです。このため：

Git は幅広い開発ツールチェーンにうまく統合されています
Git はほとんどの開発者に知られており、使用されています
Git は十分に文書化されています

またはマーキュリアル

Git の代替として、Mercurialも非常に優れています。Mercurial には、Git よりもわずかにクリーンで、より直交的なコマンドセットがあります。2000 年代後半には、主に Windows を重視するコア開発者がいたため、Windows システムでは Git よりもサポートが充実していました。

GUI

コマンドラインの代わりに GUI を使用したい場合、gitSourceTreeは、 Git と Mercurial の両方にクリーンなインターフェイスを提供する優れた Windows および OS X アプリケーションです。hg

廃止された推奨事項

2010 年現在、私はMercurialとTortoiseHGを推奨しています。これは、Windows サポートと分散バージョン管理機能の最適な組み合わせです。

2006 年から 2009 年にかけて、Subversion (SVN) をお勧めしました。これは無料で、ほとんどの IDE との統合が優れているためです。組織内で出張したり、より分散したモデルを好む場合、すべてのローカル作業に Git を使用できますが、コードを共有したい場合は SVN リポジトリにコミットできます。これは、集中型システムと分散型システムの間の優れたバランスです。開始するには、 Git-SVN クラッシュコースを参照してください。SVN を使用する最後の、そしておそらく最も重要な理由はTortoiseSVNです。これは SVN の Windows クライアントであり、誰でも右クリックするだけでリポジトリにアクセスできます。私の会社では、これが非開発者にリポジトリへのアクセスを与える優れた方法であることが証明されています。

score 3 · Accepted Answer

DVCS (BitKeeper、git、Bazaar、Mercurial など) が分散されているため、中央の「標準的な」SCM サーバーの負荷が削減されます。注意点は、これらはかなり新しいテクノロジであり、その使用法に慣れている人は多くないということです。

古い集中型モデルに固執したい場合は、余裕がある場合は Perforce をお勧めします。Perforce にお金を払いたくない場合は Subversion をお勧めします。CVS よりも Subversion をお勧めします。なぜなら、それには十分な機能があり、十分な価値がありますが、CVS を既に知っている開発者が快適に使用できるほど十分に似ているからです。

score 3 · Accepted Answer

要約: 私が個人的に git を使用した経験のあるシステムの中で、これが最もうまく処理できるでしょう。

詳細：

私は多くの開発者がいるいくつかの大企業で働いてきました。以前の仕事 (約 500 人の開発者と推測します) では、(時代のせいで) RCS と CVS を使用していました。別のグループも ClearCase を使用しました。ClearCase グループには重大な問題がありましたが、それが ClearCase によるものなのか、ClearCase の方法論の誤用によるものなのか、ClearCase の管理スタッフの不手際によるものなのか、私にはわかりませんでした。

私が今一緒にいる会社 (10000 人をはるかに超える開発者ですが、ほとんどの人が単一のプロジェクトと考えるものに 1000 人以上いるとは思えませんが、単一の製品にはそれだけの数の開発者がいます)、私たちは CVS を使用しています。 (歴史的な理由から)、SVN (簡単な移行パスだったため)、SVK (当時は良かったが、お勧めしません)、Mercurial (申し訳ありませんが、直接の経験はありません)、Perforce (同上)、Git.

過去にワープしてそこに閉じ込められない限り、RCS や CVS はお勧めしません。それらには優れた点がありましたが、最新のバージョン管理システムと比較して、それらを推奨するものは何もありません.

SVN は安定して成熟しており、分岐は CVS よりもはるかに高速です (大規模なプロジェクトでは数分ではなく数秒です)。ただし、これらのブランチをマージすることは、まだ少し原始的です (単純なケースでは、小さなシェルスクリプトで簡単に実行できますが、ブランチが更新されて、別の場所にもコミットされているものが取り込まれた場合、管理は非常に困難です)。SVN ソースリポジトリは、他のオープンソースリポジトリよりも多くの注意とフィードが必要なようです (ただし、商用リポジトリよりは少ないようです)。SVN には、素晴らしくシンプルな概念モデルがあります。

ただし、「いくつかのサイト（非常に遅いリンクの背後にあるサイト）」があり、SVNはそのために機能しますが、それほどうまく機能しません。「遅いサイト」の人々にとっては遅いだけでなく、「遅いサイト」の人々がいくつかの操作を行っている間、他のすべての人は締め出されます。それにもかかわらず、SVN は、中央レポへのアクセスがかなり良好な (高速で信頼性の高い) グループに対してはうまく機能すると思います。

SVK は、私たちの「遅いサイト」でよりうまく機能しました (そして、より多くの「切り離された作業」を可能にしました)。また、複雑なマージでは、SVN よりもはるかにうまく機能しました。SVK はメンテナンスされなくなりました。それ以外の場合はお勧めします。

Git は、大企業が真剣に検討するには比較的若いものですが、それはさておき…</p>

それは良い仕事をしますが、学習曲線はかなり急です。集中型ソース管理システムをすでに使用しているグループはなおさらです。ここで役立つことの 1 つは、「X はプロジェクト Y の信頼できるリポジトリです」などを形式化し、古いレビュープロセスなどをすべて取得してそのリポジトリに適用することです (R からのコードレビューと承認が必要な場合)。古いソース管理システムのトランクにチェックインする前に T が合格したテストは、信頼できるリポジトリのマスターブランチにコミットする前に同じことを要求します)。

いくつかの点で、git は実際にはSVN などよりも大きなグループでうまく機能します。権限のあるものとして指定したリポジトリにコミットできる人を少数にすることで、プロセスを強制できます。それらの人々は、変更をレポにプルする前に、すべての「プロセス」に従っていることを確認する責任があります。Git は、誰が変更を加えたのか、誰がそれらを統合したのかを追跡します (SVN は多くの場合、間違っているようです)。

Git を使用すると、ブランチを作成するのに SVN よりもさらに安価になります (切断して行うことができ、SVN では 1 秒未満であるのに対し、SVN ではおそらく 3 秒かかります)。大きな問題は、マージが非常に簡単であることです。ブランチを開始した、作業の半分を完了した、1 か月間別の作業をしなければならなかった、他の人が 1 か月でベースプロジェクトを変更したためにブランチのソースを更新した、2 回目の作業を行ったなどの場合でも、作業の半分が横道に逸れ、後で戻ってくる必要があり、作業の 3 番目の半分、さらに外部の更新などがあることがわかりました… vs. はアップデートから入ってきて、本当にマージが必要なものの量を最小限に抑えます。

git の嫌いなところはたくさんありますが、そのほとんどは「一部のツールは鋭利で注意が必要」に行き着きます。SVN のようなものには存在しない多くの操作のようなものは、リポジトリにのみ存在するコミットでのみ実行する必要があります (他の人が見た履歴を編集しないでください!)。他のソース管理システムにも同様の問題がありますが、git は履歴を編集して「クリーン」に保つことに重点を置いているため、無視するか、いつ安全か災害かを知る必要があるツールとツールのオプションが増えています。全体として、私が使用した他のバージョン管理システムよりも優れていると思います。

Perforceに関する私の中古情報は、「SVNよりも優れているが、そうではない」というものです。Mercurial に関する私の中古情報は、「詳細を除いて多かれ少なかれ git に似ており、Git の方が好きな人もいれば、Git の方が好きな人もいます」です。

もちろん、1000 人以上の開発者を抱える会社では、使用するソース管理システムのサポート契約を結ぶことをお勧めします。git については、github:fi を調べます。

score 3 · Accepted Answer

第一に、CVS に大きな NO を付けることです。2008 年に CVS を使用することは、92 Isuzu Trooper を運転するようなものです。それらが移動中であり、人々がそれらを維持するためにお金を費やす唯一の理由は、純粋に感傷的な理由によるものです。CVS は技術的に古い帽子であり、あなたはそれを後悔するでしょう。

私も、そのような規模の会社では、一般的にオープンソースツールから遠ざかっています。Subversion は非常に優れた小さなツールであり、非常に堅牢ですが、万一ダウンしたり、気付いていなかったバグに遭遇したりした場合は、3,000 人が放置されている間にそれを修正する責任があります。そういう意味ではPERFORCEは安くてオススメです。

SCM の専門家を自称する人の多くが「無料」を選択していることに驚きました。表面的には、管理者にとっては素晴らしいように見えますが、銃の下にいるときは、高品質のサポートチームがあなたの側にいるのに役立ちます. 日曜日の午前 3 時に目が覚めたとき、シンガポールのチームが仕事をすることができず、「無料」が良いアイデアだとは思わないでしょう。

ソース管理ツールはミッションクリティカルです。会社の資産や知的財産について話しているのです。ソース管理ツールをケチってはいけません。

score 2 · Accepted Answer

CVS を使用しないでください!! CVS モデルが必要な場合は、Subversion がはるかに優れた代替手段です。

score 2 · Accepted Answer

わかりました、完全な免責事項: 私はIntegrityと呼ばれるソフトウェア構成管理プラットフォームの一部として「エンタープライズ」企業向けのバージョン管理システムを作成するMKSと呼ばれる会社の開発者です。何とか何とか何とか、明らかなプラグ。

ですので、正直なところ質問にはお答えできません。

ただし、分散バージョン管理を提案する人々は、大企業にとって非常に重要な何かを見落としていることを指摘しておきます。彼らにとって、開発者がバージョン管理システムを扱う際にどれだけの柔軟性を持っているかは、出荷されるコードのすべての行を完全に制御できることよりも重要です。規制への準拠と監査は、合併がいかに苦痛であるかよりも、はるかに重要な関心事です。

1,000 人以上の開発者を抱える企業は、誰もが本来すべきことを行っており、誰もすべきでないことをしていないことを知りたいと考えています。すべてが追跡され、管理者は PowerPoint スライドに貼り付けることができる美しいレポートとグラフを取得します。彼らのマネージャーのために。

大企業がこれらのことを特に気にしない場合、個々の開発チームに任せて独自のことを理解する可能性がはるかに高くなります。その場合、1000 人以上の開発者がさまざまなツールの寄せ集めを使用しています。当時最も便利だと思われたものに基づいています。

score 1 · Accepted Answer

このような大規模な組織の場合は、単一の特定の SCM を義務付けないでください。

彼ら全員が同じコードに取り組んでいるわけではないと確信しており、チーム自身が最も快適なものを選択できるようにすることは価値があります.

(Git、SVN、内部レガシーシステムのいずれかを選択する方法を理解するために、トレーニングを提供する必要がある場合があります。)

score 1 · Accepted Answer

悲観的ロック ( http://old.davidtanzer.net/?q=node/118 ) メカニズムを持たない SCM を使用します。特に、大規模なプロジェクトで同じファイルを同時に「編集」できるようにするためです。

個人的には、配布用のソリューションを備えた SVN を選択しますが、SVN では、変更したもののみを送信するため (コミットごとに非常に少ないはずです)、ネットワークのオーバーヘッドは非常に小さくなります。また、サーバーの負荷は、ある時点までより多くのハードウェアで処理できます。SVN を使用する場合のハードウェアスケーリングの上限をまだ見つけていません。

他の選択肢には、Linux カーネルの人々が使用する「git」が含まれる場合がありますが、私は実際にその経験がありません。

score 1 · Accepted Answer

あなたの組織に 3000 人の開発者がいて、全員が同じコードベースに取り組んでいるかどうかは疑問です。私は中規模から大規模のソフトウェア会社で働いていますが、おそらく会社全体ではそれほど多くはありませんが、独立したプロジェクトもたくさんあります。

内部的には、製品で使用するために他のグループにリリースを提供するグループもあります。これは、SCM システムを通じて管理されていません。

私たち自身のグループには独自の SCM がありますが、アクティブな開発者は約 25 人しかいません。私たちは CVS を使用していますが、正直なところ、CVS にはあまり対応できていません (移行したいのですが、多くのスクリプト/コミットフックや、変更に多くの作業が必要なその他のビット & ピースがあります)。妥当なサイズのコードベースで CVS を使用する際の問題は、多くの操作が非常に遅く、他の開発者をロックアウトすることです。

score 1 · Accepted Answer

パーフォース

CVS と比較して perforce say について私が気に入っているのは、ブランチ管理がより洗練されている必要があり (それでもかなり簡単です)、ブランチ/ラベルなどを作成するために中央の官僚機構をバグる必要がないことです。つまり、個々のチーム (または開発者) は、他の誰かが集中管理するメインラインに提出する前に、ソースコンポーネントを好きなように管理できます。

ああ、それは最高の GUI の 1 つを備えていると同時に、最高級のシチズンコマンドラインインターフェイスを備えているとも言えます。私は通常 GUI が嫌いですが、GUI は機能します。

score 1 · Accepted Answer

1 つのソフトウェアに 1,000 人以上の開発者が取り組んでいる場合、独自のツールに投資するリソースがあります。どちらを選択しても、状況に適応させるために多くの作業を行うことになるでしょう。

Microsoft の Team Foundation Server は、Microsoft 内のいくつかの非常に大規模なチームで使用されており、TFS チームはそれをうまくスケールアップできるように取り組んでいます。また、ソース管理とバグ追跡の統合も魅力的です。安くはありませんし、管理も面倒なので小さなチームにはうまくスケールダウンできませんが、あなたの状況では、そのコストを支払う余裕があります. また、問題が発生したときに、Microsoft のような大規模なサポート組織に電話できるようにしたい場合もあります (ただし、フリーソフトウェアを使用する場合は、そのサポートを社内で行うオプションがあります)。

会社に 1000 人以上のエンジニアがいて、別々に出荷されるソフトウェアに取り組んでいる場合、それぞれを独自のサーバーに配置したいと思うでしょう。これにより、パフォーマンスのスケールと管理が向上します。ただし、ソース管理のテクノロジは 1 つだけにすることを強く主張します。

score 1 · Accepted Answer

ここで DCVS-es を提唱している人々のほとんどが、ある種のファンボーイと見なされていることに恐怖を覚えます。DCVS は、クラウドコンピューティングやソーシャルメディアなどと同じように、さらに別の流行語としてレンダリングされます。

ここにいる何人かの人々は、特定のハードウェア設定、テーブルに信頼性をもたらすと想定されている (または可能でさえある) 特定のディスクストレージと共に SVN を使用することを提唱しています。それは、SCM の 2 つの主な目的の 1 つ、つまりデータの整合性を確保することを無効にするだけではありませんか?

過去のすべてのリビジョンにわたってソースベース全体の整合性を確保するためのデータストレージレベルに関する十分な情報がありません。データを別のマシンに移行したい場合はどうすればよいですか? 完了するまですべての開発を停止することなく、段階的に移行したい場合はどうすればよいでしょうか? セキュリティ上の問題があり、誰かがあなたのメインコピーを台無しにしてしまったらどうしますか? 最後の有効なものをどのように見つけますか? ストレージの整合性はそこまでしか到達できず、これらの問題を解決する手段はありません。それはまさに、不適切なレベルの抽象化で動作しているからです。あなたが心配しているストレージではありません。それはあなたのコードベースです。

別の問題。同じプロジェクト内で 3000 人以上の人々が実際に活動できるとは信じられない人もいます。彼らは「あなた自身のscmを焼いてください」と言いますが、これは「ええ...そうです... 3000人以上の開発者...それで頑張ってください」という別の言い回しだと思います。同時に、より多くの人々が関与するプロジェクトもあります。エンジニアリングから法律まで、あらゆるものを取り上げます。しかし、どういうわけか、ソフトウェア開発に関しては、それは不可能です。思考 (私は想像します) は次のようになります。3000 人以上が同じファイルにアクセスしていますか? 今、それはできません。そして、ええ、それは正しいです。それはできません。問題は、なぜ 3000 人以上の人々が同じファイルにアクセスできるようにするのかということです。自然のどこでそのような状況を見つけることができますか? 3000 人以上の弁護士が、最終的にすべてに同意するまで、1 つのドキュメントを互いに送信しますか? 人々はそのようには働きません。そのような現実で働くことは決して不可能です。しかし、集中型 CVS は理論的にはそれを可能にします。さらに悪いことに、人々は、知らない人と実際に仕事を調整することを強いられます。そのような状況では、賢い人が乗っていても問題ありませんが、何千人もの人々の中で、一人一人が馬鹿ではないことを保証することは非常に難しいと思います. それは単によくある愚かな間違いを犯すことです。誰もが (文字通り) エラーを犯します。なぜいきなり会社全体に知らせたがるのですか？そのように動作しません。そのような現実で働くことは決して不可能です。しかし、集中型 CVS は理論的にはそれを可能にします。さらに悪いことに、人々は、知らない人と実際に仕事を調整することを強いられます。そのような状況では、賢い人が乗っていても問題ありませんが、何千人もの人々の中で、一人一人が馬鹿ではないことを保証することは非常に難しいと思います. それは単によくある愚かな間違いを犯すことです。誰もが (文字通り) エラーを犯します。なぜいきなり会社全体に知らせたがるのですか？そのように動作しません。そのような現実で働くことは決して不可能です。しかし、集中型 CVS は理論的にはそれを可能にします。さらに悪いことに、人々は、知らない人と実際に仕事を調整することを強いられます。そのような状況では、賢い人が乗っていても問題ありませんが、何千人もの人々の中で、一人一人が馬鹿ではないことを保証することは非常に難しいと思います. それは単によくある愚かな間違いを犯すことです。誰もが (文字通り) エラーを犯します。なぜいきなり会社全体に知らせたがるのですか？何千人もの人々の中から、彼らの一人一人が馬鹿ではないことを保証するのは非常に難しいと思いますが. それは単によくある愚かな間違いを犯すことです。誰もが (文字通り) エラーを犯します。なぜいきなり会社全体に知らせたがるのですか？何千人もの人々の中から、彼らの一人一人が馬鹿ではないことを保証するのは非常に難しいと思いますが. それは単によくある愚かな間違いを犯すことです。誰もが (文字通り) エラーを犯します。なぜいきなり会社全体に知らせたがるのですか？

と言う人もいるかもしれませんが、すべての人にコミットアクセス権を与える必要はありません。まあ - それは不正行為です。一元化された環境で分散ワークフローを構築するのは、まさに絶望的な試みです。突然、2 レベルのツリーができました。コミットアクセス権を持つ人は、そうでないすべての人によって作業を送信します。そこまで行ったのなら、避けられないこと、つまりソースベース全体の単一の共通バージョンは存在せず、今後も存在しないことに同意しないのはなぜですか。人々は、簡単に融合できる独立した環境内で作業する必要があります。

最近は多くの DCVS があります。個々のファイルではなく、コンテンツを追跡するこのアプローチを採用しているのは Git だけです。Mercurial もありますし、Bazaar もあります。したがって、2 つのプロパティは互いに依存しません。

特定の DCVS を推奨したいわけではありません。しかし、推奨されるソリューションのほとんどが配布されておらず、データの整合性が保証されておらず、実際には CVS がまったくないよりも悪い状況では、何かを書く必要があると感じました。問題は、どの DCVS が仕事をするのに最も適しているかということです。

score 1 · Accepted Answer

AccuRev を使用します。svn、cvs、clearcase (base、ucm)、ccc/harvest を使用しましたが、どれも AccuRev の強みに勝るものはありません。「複数のサイトを持つ 3000 以上の開発者組織」? そのためにAccurev分散ソリューション（AccuReplica）を使用できます-つまり、1つのマスターサーバーと、リモートサイトに必要な数のレプリカがあることを意味します（したがって、「低速リンク」を持つ人はそれほど苦しむことはありません）

何よりも、AccuRev は独自のアプローチをもたらします - ストリームベースの SCM ツールの真に新しいコンセプト/設計/実装です。ClearCase-UCM が行った (悪い) 方法ではありません (ClearCase の「ストリーム」は最終的にはブランチになったため)。

最良の方法は自分で試すことです。ツールをいじるのに十分なライセンスを備えた 30 日間の試用版が提供されていることは知っています。試してみれば、他のツールを検討する必要はありません。私の約束。

score 1 · Accepted Answer

私はビットキーパーを使用します。私は bitkeeper、clearcase、accurev、perforce、subversion、cvs、sccs、rcs を使用してきましたが、これらすべての bitkeeper の中で最高のものをはるかに上回っていました。私は git をいじり、その速度に感銘を受けましたが、その UI は少し扱いにくいと思いました (ただし、その意見は、2、3 半日使用しただけで形成されました)。

bitkeeper の GUI はかなり不格好に見えますが、非常に機能的です。ビットキーパーのコマンドラインツールは間違いなく最高の組み合わせであり、そのマージ機能は非常に優れていました。

bitkeeper について私が最も気に入った点 (これはおそらくすべての分散システムに当てはまることです) は、ブランチが非常に安価であるということです。ブランチを作成することは、恐れるものではなく、生き方でした。

score 0 · Accepted Answer

オプションを見てみましょう。

1-PERFORCE。多くの企業で使用されています（人々がそこで言ったように）Adobe、Amazon、MS、Google成長し、進歩し、毎日ソフトウェアを販売して食べ物をテーブルに置くことに依存している企業、それが彼らの選択です。多数のサイトなどでサポートされている「グローバルソリューション」が必要な場合は、これが私が行う方法だと思います。Win/ Linuxに適しています（ただし、Macについてはわかりません）。

2-SVN。大規模なチームでも使用されており、KDEは現在リビジョン880,000のそれ（巨大で巨大なプロジェクト）を使用しています（はい！）WindowsとLinuxの両方の使用に非常に実用的です（いくつかの面でTortoiseSVNを平均以下と呼んでいますが）商用サポートを契約できます同じように。Windows / Linux/Macにも適しています。

3-Accurev私が「エッジの効いた」ことをしようとしていた場合。最初にテストして慣れなければ、会社全体に展開することはできません。

4-MS Team Foundationこれは良い解決策かもしれませんが、試したことはなく、おそらくWindowsのみです。

5-Git / Bzr / Hg-BzrとHgには「カメ」があるので、Windowsに適しています（成熟度についてはわかりませんが）Gitは、非常に優れているにもかかわらず、当面はLinuxになります（そして数年前よりもはるかに良く、使いやすいです）。

JOSEがClearcaseを使用することは絶対にありません。期間それは皆のお金と時間と正気の無駄です。

回避する：CVS/クリアケース/古いもの

score 0 · Accepted Answer

0

AdobeはPerforceを使用しています

于 2008-09-15T18:36:29.503 に答える

score 0 · Accepted Answer

3000 人以上の開発者が同じコードベースで作業しているという意味なら、私には手がかりがありません。さまざまな場所で数百のプロジェクトに取り組んでおり、標準が必要な場合は、大規模なオンラインユーザーサポートで人気のあるものを選びます。つまり、Google で 10 回ヒットするような目立たないものではありません。

個人的には SVN で解決します。私は数百人の開発者がいる IT 部門に所属しており、望ましいソース管理アプリは SVN です。

:)

//W

score 0 · Accepted Answer

Perforce は適切なシステムであり、適切に拡張できます。

私は約 5000 人の従業員を抱える組織で働いていますが、perforce は高速で効率的なシステムです。スケーラビリティが高く、ブランチのサポートが良好で、アトミックコミットがあります。各変更には、「ソフトウェア考古学」およびその他の優れた機能のホストに使用できる変更番号があります。

さらに、Windows、Mac、および Unix を適切にサポートしており、優れたコマンドラインや優れたスクリプトサポートも備えています。

以前に CVS を使用したことがありますが、約 25 ～ 50 人を超えるエンジニアのグループにはうまく拡張できません (主にアトミック操作とパフォーマンスのため)。

score 0 · Accepted Answer

Perforce も私の票を獲得します。私はそのような大規模なプロジェクトでそれを使用したことはありませんが、私の環境では絶対に堅実です. また、大規模なプロジェクトの印象的な履歴書もあります。

[うわさ] Microsoft が Vista に使用したと聞いた.

score 0 · Accepted Answer

実際に Team Foundation Server をチェックしてみます。これは拡張可能な非常に優れたシステムであり、内部の IT 部門を通過するのはおそらく簡単です。Windows 中心であることはわかっていますが、Linux/Mac 用のアドオンも使用でき、接続が遅いサイトではプロキシを使用できます。

また、大規模な組織で 2 つのシステムを使用することを検討します。別々のケースで最善を尽くすのに役立つ場合があります。

score 0 · Accepted Answer

Perforce は、Google の単一サーバーで 5000 人以上のユーザーに拡張できることが証明されています。次を参照してください: Life on the Edge: Monitoring and Running a Very Large Perforce Installation

最大規模のソフトウェア企業の多くは、Perforce を単独で、またはメインの SCM として使用しているようです。例: Adobe、Cisco、SAP、Symantec、EA、UbiSoft、Autodesk はすべて Perforce ユーザーです。完璧ではありませんが、それでも SVN や TFS よりも優れています (どちらもそれ自体が悪いわけではありません)。

score 0 · Accepted Answer

Perforce と TFS は、私が知っている唯一のオプションです。どちらもマイクロソフト内の大規模プロジェクトで使用されていることを知っています。Vaultはそこまで大きくなるかもしれませんが、500 ～ 1000 ユーザーを超えるかどうかはわかりません。

score -1 · Accepted Answer

Visual Studio を使用する開発者には、TortiseSVN クライアントと Visual-SVN アドオンを備えた SVN を強くお勧めします。

score -1 · Accepted Answer

当社ではエイリアンブレインを使用していますが、現在Perforceに移行しています。Perforce には必要なものがすべて揃っています。コードとデータを処理し、継続的インテグレーションのためのツールを統合し、ローカル (開発者ごと) リポジトリを処理するため、サーバーにコミットする前にローカルリポジトリにチェックインできます。

私はPerforceに投票します

score -1 · Accepted Answer

全員が同じ製品に取り組んでいる場合は、おそらく Perforce です。

小規模なプロジェクト (2 ～ 50) が多数ある場合は、複数の Subversion (SVN) ボックスを実行します。

score -1 · Accepted Answer

-1

TortiseSVN (Windows 上) を使用した SVN は素晴らしいです。強くお勧めします。

于 2008-09-16T00:01:29.080 に答える

score -1 · Accepted Answer

私は Subversion のファンですが、オープンソースやクローズドソースの優れた選択肢がたくさんあります。CVS は現代の SCM とは比べ物にならない (アトミックなコミットなどはない) ので、私は避けたいと思います。

おそらく誰かが SourceSafe を提案するでしょう。ペストのようにそれを避けてください。SourceSafe は静かに歴史を破壊し、悲しみの終わりを引き起こしません。少しグーグルすると、それについて詳しく教えてくれます。

Subversion は成熟しており、多くの優れたツールと IDE 統合を備えています。HTTP を使用してリポジトリにアクセスするため、ほとんどのネットワークでうまく機能します。

私は数年前に SCM 変換に取り組みましたが、できる最善のことはそれらを試してみることです。SCM ベンダーは、評価のためのデモと技術サポートを提供します。

SCM の選択は簡単なことではありません。コードベースとワークフローに大きく依存します。一部のシステムは、巨大なコードベースを他のシステムよりも適切に処理します。多くのブランチとマージを他のものよりもうまく処理するものもあります。リモートアクセスに適したものもあれば、他のものよりも優れているものもあります。よりきめ細かいセキュリティモデルを持つものもあります。

システムと対話するすべての人を集めて、必要なもの/欲しいもののリストを作成します。デモを入手し、コードをインポートして試してみてください。大規模なグループの SCM を選択することは主要なプロジェクトであり、そのように扱われるべきです。

score -1 · Accepted Answer

Subversion は、スケーリングと分割が簡単です。Perforce は、ほんの一握りの従業員に対して数千ドルの費用がかかり、非常に高価です。さらに、Subversion が提供しないものは何も提供しません。

Subversion は本当に簡単で、cvs より優れています。

Windowsのサポートだけが優れていれば、gitをお勧めします

score -1 · Accepted Answer

Subversionを使用します。Subversion は、大規模な開発者コミュニティを持つ多くの大規模な分散型オープンソースプロジェクトで証明されています。また、Subversion コミットのトランザクションの性質により、接続が信頼できない状況に最適です。

version-control - 1000 人以上の開発者組織にどのバージョン管理システムを使用しますか? なんで？

33 に答える 33

摩擦を減らす

Git を使用する

またはマーキュリアル

GUI

廃止された推奨事項

Related

Reference