git / mercurial / bazzrシステムが集中システム（subversion、perforce）よりも優れている理由を検索しましたが、ビジネス上の理由は見つかりませんでした。

DVCSを非技術者に販売しようとした場合、DVCS が利益を上げるためにどのような議論を提供しますか。

私はまもなくマネージャーにgitを売り込みます。subversionリポジトリーの変換には少し時間がかかり、smartgitライセンスの購入にはいくらかの費用がかかります。

編集私はこの質問を集中型と分散型の一般的な議論にしようとしましたが、必然的にgit vs subversionに変わりました。確かに、転覆よりも優れた集中システムがあります。

うーん、マネージャーだったので、私はこれに対して2つの即時の「ひざまずき」反応があります。

• まだトレンディーである以外にgitを売り込んでいる理由がまだないのですか？
• 同様に、Subversionはどのように失敗し、交換が必要になりますか？

私は、実際には否定的ではありません-おそらく（状況に応じて）行われるべきケースがあると思いますが、もしgitがsubversionよりも「良い」という場合は、実際にはありません。

また、デメリットを列挙できるようにする必要があります-移行とリツールのオーバーヘッドを既に特定している-他に問題はありますか？たとえば、バックアップされた素敵な中央のリポジトリはどうなりますか？継続的インテグレーションビルドサーバーとどのように統合しますか（サーバーがない場合は、gitを忘れて最初にソートしてください）。セキュリティと追跡について-SVNは適切なログインと権限で実行されます。

私の考えでは、利点は柔軟性、より良いマージ、ビルドを壊さずにローカルコミットを実行できることなどです。欠点は、制御の欠如とその柔軟性にあります。

あなたがしたいのは、「より良い」subversionクライアントとしてあなたのマシンでgitをローカルに実行することだけかもしれません（私はmercurialを使用してこれをやっています）。

うーん、おそらくこの答え全体が本当にコメントなのでしょうか？ビジネスケースの特定に役立つかどうかを確認するために、（環境内の）git over subversionについてここで（質問で）ケースを作成する必要があります。

FWIW、リポジトリの特定のインスタンスをトランク/参照ソースに簡単に指定できること、そしてそれがビルドサーバーに配線する方法であることを知っています-DVCSでは管理上の決定よりも多くの違いがありますアーキテクチャに固有の何か。

迅速で簡単な分岐とマージにより、開発者はコードをより生産的に使用できるようになります。すべての新機能を分岐して、後でマージできるからです。開発プロセスをよりスムーズに進めます。また、分散型の性質により、すべての開発者がコードの完全なコピーを持つことができるため、集中化されたサーバー障害がすべてのコードを停止する心配はありません。おそらく他にも理由がありますが、これら2つはGitを使用する最大の理由です。

開発者が単独で作業している場合でも、バージョン管理が生産性（ひいては利益）を高めることを主張できると思います。

優れたDVCSは、チームの一員として作業している場合でも、同じ生産性の利点を認識します。各開発者はバージョン管理のすべての利点を享受できます。変更をプッシュする準備が整うまで、他の開発者が行っていることと一緒に。

• バグごとのブランチ
• 差分の待ち時間を短縮しました。
• ピアレビューを行っているときに、ブランチの履歴を非常に迅速に任意にナビゲートできること。
• 集中型サーバーにアクセスできない場合でも、履歴全体にアクセスできます。オフィスにいなくても、電源は切れましたが、ラップトップのバッテリーはまだ動作しています。

これらのことにより、ソロでもチームでも、より効率的に作業できます。より効率的な作業=開発時間の短縮=市場投入までの時間の短縮=利益。

自分のブログにリンクすることは許してくれますが、このテーマに関する記事を書いています。

• ヒントを常にコンパイルする必要がある理由
• DVCSが優れた中央制御を提供する理由
• DVCSで分岐が優れている理由
• 分散分岐モデルがCVCSでうまく機能しない理由。

関連性がない場合は、自由に投票してください。

簡単に言うと、DVCSは分岐モデルを簡単にし、開発者の大規模なグループがお互いの足指を踏まないようにすることができます。これにより、生産性と日々のビルド品質の両方が向上します。バージョン管理の面倒なコラボレーション部分はローカルリポジトリで実行できるため、中央リポジトリはよりクリーンで高品質になります。また、分岐するタイミングの決定は、1.0が他の部門によってまだクリーンアップされているときに、ある部門が2.0で作業を開始する準備ができている場合など、効率に大きな影響を与える可能性があります。DVCSでは、これらの決定を委員会ではなくローカルレベルで行うことができます。

DVCSに対する私の主張は次のとおりです。

• 分岐は壊れていません。これにより、機能の開発や既存の製品にパッチを適用する際の摩擦が少なくなります。摩擦には時間がかかります。

• 最新のシステムに移行することで、最先端の開発者がより魅力的になり、より良い製品の文化につながり、より多くの製品を販売できるようになります。

• 非ネットワークコミットは高速であるため、開発者は頻繁にコミットでき、きめ細かいバグの検出と分析につながります。

基本的に、摩擦を減らすことです。これにはMudaという用語があります。摩擦が大きければ大きいほど、物事を行うのが苦痛になります。痛みが多くなればなるほど、得られる利益は少なくなります。

自立している場合は謝罪しますが、ビジネスケースに不確実な条件を入れないでください。

SVNは開発者の生活を悲惨にします。そして、それはソフトウェアビジネスを悲惨なものにします。

... DVCSの使用を開始するまで多くの人が気付かない方法で。 これは、おそらく最も重要なビジネスケースです。どうして？まあ、優れた開発者を見つけて維持するコストと比較して、DVCSへの切り替えのコストはほとんどありません。

以下を考慮してください。

• SVN（および他のほとんどのCVCS）で最も簡単な操作を除くすべての操作には、ネットワークアクセスが必要です。ほとんどのDVCSで、ネットワークアクセスは操作pushまたはpull操作を行うときにのみ発生します。これは、重要なコマンドが遅いことを意味します。コマンドが永久に使用されている場合はどうしますか？私は個人的に私が待っている間、programmers.seまたはハッカーのニュースを閲覧しに行きます。簡単に言えば、DVCSを使用すると、プログラマーは自分の好きなこと、つまり会社のソフトウェアを作成することに集中できます。
• SVNは、刑務所がシャワーに石鹸を落とすのをサポートするのとほぼ同じ方法で分岐をサポートします。したがって、SVNは開発者に変更を加えるために絶えずお互いに争うことを強制します。
• SVNがダウンすると、ダウンします。開発者が仕事をすることができたとしても、仕事をすることは非常に困難になります。したがって、SVNは、開発者がインフラストラクチャに100％バグがないことに依存することを強制します。
• 最近では、gitは急速にマインドシェアを獲得し、SVNは急速に失いつつあります。 SVNを介してDVCSを使用するメリットがない場合、プログラミングコミュニティができるだけ早く変化するのはなぜですか？

このすべては何になりますか？私はまだDVCSにSVNを好む正直な試みを与えられた開発者に会ったことがありません。もう1つ迷惑で大胆な発言をすることができれば、SVNは開発者が使用することを強制する「必要な悪」です。Gitは、開発者の生産性と満足度を向上させるツールです。

（太字のステートメントは、焦点を当てる必要がある特定のステートメントであることを指摘しておく必要があります。残りはコンテキストを提供するだけです。）

私が考えることができる唯一のことは、gitがネットワーク接続なしで動作するということです。それ以外のすべてのものは、かなり長い間、subersionまたはperforceを使用する技術ユーザーに販売するのが難しい場合さえあります。

トラブルがある場合の違いを示す

10年前のリポジトリを移植してから6か月前にgitに切り替えました。

これまでのところ、少し実験して次のことがわかりました。

• 分岐とマージはほとんど無痛です。これにより、つま先を踏むことなく、個別の機能やバグ修正を簡単に行うことができます。また、特定のバグ修正を他の場所にも非常に簡単に適用できます。

• 設計により堅牢です-中央サーバーが利用可能であることに100％依存しておらず、そうでない場合は、一時的に任意のクローンをホットリプレースメントとして使用できます。これにより、重大な障害点が取り除かれます。SVNサーバーが何らかの理由でダウンした場合、だれもSVNの作業を行えなくなります。何らかの理由で中央のgitリポジトリがダウンした場合でも、ローカルで作業およびプッシュ/プルを行って、コミットが複製されるようにすることができます。まさにこの目的のために、複数のオフサイトリポジトリを持つことさえできます。

• リポジトリの相互作用が簡素化されます。CVSの場合、基本的に、何らかの情報が必要なときは常にアクセスする必要がありました。gitの場合、リポジトリ全体がローカルで利用できるため、多くのことが高速になります。

そのため、毎日のルーチンではそれほどメリットはありませんが、何かが正常に機能していない瞬間は非常に明確です！

したがって、ビジネスケースでは、災害が発生したときに何をするかを検討することをお勧めします...

分岐とマージの容易さが最も具体的な理由ですが、誰かを納得させるには、それが物事をどのように改善するかの具体的な例を与える必要があります。

アプリのパフォーマンス改善に取り組んでいるプログラマーが数人いて、彼らが実験段階にあり、書いているコードがマスター/トランクブランチの一部になるかどうかわからないとしましょう。ただし、コードを頻繁に共有し、行き止まりになる可能性のあるアイデアを試す必要があります。このような頻繁な分岐とマージをsubversionでどのように管理しますか？簡単な答えは、そうではないということです。dvcsを使用すると、非常に簡単です。プログラマーは、ブランチで新しいアイデアをすばやく試し、他のユーザーと共有してから、そのアイデアを採用するかどうかを決定できます。

SubVersionを廃止するビジネスケースは、分岐サポートが製品の安定化と保守の障壁であるということです。製品をリリースしてから開発を続ける必要がある場合は、ブランチが必要です。Subversionでは、開発者はブランチを適切に使用しないため、開発をTunkで維持できず、バグ修正が実際にトランクとブランチの両方にも適用されるようにします。