分散型バージョン管理 (別名、分散型リビジョン管理、分散型バージョン管理) を使用している人々と、それをどのように見つけているかについて聞きたいです。Mercurial、Darcs、Git、Bazaar の何を使用していますか? まだ使っていますか？過去にクライアント/サーバーの rcs を使用したことがある場合、それが優れている、劣っている、または単に異なると思いますか? 私が時流に乗るようになるとしたら、何を教えてもらえますか? または、そのことについては飛び降りて、ネガティブな経験をした人の話も聞きたいです。
現在、この質問の原動力となっている現在のソース管理システム (Subversion) の置き換えを検討しています。
マシンが同時にオンになっておらず、接続が非常に遅い他の国の同僚と一緒に使用したことがある人に特に興味があります.
分散バージョン管理とは何かがわからない場合は、次の記事を参照してください。
私は仕事でも個人的なプロジェクトでも Mercurial を使ってきましたが、とても満足しています。私が見る利点は次のとおりです。
もちろん、他の新しいシステムと同様に、移行中は多少の苦労がありました。SVN を使用していたときとは異なる方法でバージョン管理について考える必要がありますが、全体としては非常に価値があると思います。
私が働いている場所では、SVN から Bazaar に移行することにしました (git と mercurial を評価した後)。Bazaar は簡単なコマンドで簡単に始められました (git にある 140 のコマンドとは異なります)。
私たちが目にする利点は、ローカル ブランチを作成し、メイン バージョンを妨害することなく作業できることです。また、ネットワークにアクセスせずに作業できるため、差分を行う方が高速です。
私が気に入っている bzr のコマンドの 1 つは、shelf 拡張機能です。1 つのファイルで論理的に異なる 2 つのコードの作業を開始し、そのうちの 1 つだけをコミットしたい場合は、shelve 拡張機能を使用して、後で他の変更を文字通り棚上げすることができます。Git では、インデックス (ステージング エリア) で遊んで同じことを行うことができますが、bzr の方が優れた UI を備えています。
ほとんどの人は、コミットとプッシュに 2 つのコマンド (bzr ci + bzr push) を入力する必要があるため、移動することに消極的でした。また、ブランチとマージの概念を理解することも困難でした (誰もブランチを使用したり、svn でそれらをマージしたりしません)。
それを理解すると、開発者の生産性が向上します。誰もがそれを理解するまで、誰もが一貫性のない行動をとります。
私の職場では、約 2 か月前に CVS から Git に切り替えました (私の経験の大部分は Subversion でした)。分散システムに慣れるためには学習曲線が必要でしたが、作業環境の柔軟性とマージという 2 つの重要な分野で Git が優れていることがわかりました。
完全なバージョン管理機能にアクセスするために、VPN に接続する必要はなく、ネットワークに接続する必要さえありません。これはつまり、アイデアを試したり、衝動に駆られたときにどこにいても大規模なリファクタリングを実行したりできることを意味します。作成した巨大なコミットを忘れずにチェックインしたり、混乱したときに元に戻せないことを心配したりする必要はありません。
マージはクライアント側で実行されるため、サーバー側のマージを開始するよりもはるかに高速で、エラーが発生しにくくなります。
私の会社では現在、Subversion、CVS、Mercurial、および git を使用しています。
5 年前に始めたとき、私たちは CVS を選びました。今でも私の部門ではメインの開発およびリリース メンテナンス ブランチに CVS を使用しています。しかし、私たちの開発者の多くは、CVS ブランチ (特にそれらをマージすること) の手間をかけずにプライベート チェックポイントを作成する方法として Mercurial を個別に使用しており、約 5 人までのいくつかのブランチで Mercurial を使用し始めています。1 年以内に最終的に CVS を廃止する可能性は十分にあります。Mercurial の使用は有機的に成長しました。CVS に満足しているからといって、いまだに触れない人もいます。Mercurial を試したことのある人は皆、学習曲線をほとんど使わずに満足しています。
Mercurial でうまく機能するのは、(自家製の) 継続的インテグレーション サーバーが開発者の Mercurial リポジトリとメインラインを監視できることです。そのため、人々は自分のリポジトリにコミットし、継続的インテグレーション サーバーにチェックしてもらい、変更セットを公開します。多くのプラットフォームをサポートしているため、適切なレベルの手動チェックを行うことは現実的ではありません。もう 1 つの利点は、マージが簡単な場合が多く、困難な場合でも、マージを適切に行うために必要な情報が得られることです。誰かがマージされたバージョンを機能させると、マージ変更セットをプッシュすることができ、他の誰もその作業を繰り返す必要はありません。
最大の障害は、開発者とマネージャーの頭脳を再配線して、単一の線形ブランチ モデルから脱却させる必要があることです。これに対する最善の薬は、集中型 SCM を使用する場合は愚かで醜いことを告げる Linus Torvalds の服用です。優れた履歴視覚化ツールが役立つでしょうが、利用できるものにはまだ満足していません.
Mercurial と CVS はどちらも、Windows、Linux、Solaris を組み合わせて使用している開発者にとってはうまく機能し、タイムゾーンに問題はありませんでした。(実際、これはそれほど難しくありません。内部でエポック秒を使用するだけで、すべての主要な SCM システムでこれが正しく行われると思います)。
かなりの努力で、メインラインの CVS 履歴を Mercurial にインポートすることができました。ヒストリー移行ツールをテストする方法として、メインラインの CVS ヒストリーにコーナー ケースを意図的に導入しなければ、もっと簡単だったでしょう。これには、いくつかの Mercurial ブランチを CVS 履歴にマージすることが含まれていたため、プロジェクトは初日から使用されていたように見えます。
私たちのシリコン設計グループは Subversion を選びました。それらは主に私のオフィスから 8 タイムゾーン離れており、オフィス間のかなり良好な専用回線でさえ、SUBversion のチェックアウトは面倒ですが、実行可能です。集中型システムの大きな利点は、すべての分散リポジトリを巨大にすることなく、大きなバイナリ (ベンダー リリースなど) をシステムにチェックインできる可能性があることです。
Linux カーネルの操作には git を使用します。ネイティブの Windows バージョンが完成すれば、Git の方が適していると思いますが、Mercurial のデザインは非常にシンプルでエレガントなので、そのまま使い続けるつもりです。
私自身は分散ソース管理を使用していませんが、これらの関連する質問と回答から洞察が得られるかもしれません。
私は個人的に Mercurial ソース管理システムを使用しています。私はそれを1年以上使用しています。実はVSCは初めての経験でした。
私は Git を試してみましたが、必要なものに対して多すぎることがわかったため、実際に押し込むことはありませんでした。Mercurial は、多くのコマンドを共有しているため、Subversion ユーザーであれば簡単に習得できます。さらに、リポジトリの管理が非常に簡単であることがわかりました。
コードを人々と共有するには、次の 2 つの方法があります。
非常に強力でありながら、非常に簡単に操作できます。しかし、一般的に、VSC の選択はプロジェクトのニーズに大きく依存します...
大きなプロジェクト（GHC）や多くの小さなプロジェクトでdarcsを使用しました。私はdarcsとの愛/憎しみの関係を持っています。
プラス：リポジトリの設定が非常に簡単です。リポジトリ間で変更を移動するのは非常に簡単です。クローンを作成して、別々のリポジトリで「ブランチ」を試すのは非常に簡単です。理にかなっている小さなコヒーレントグループで「コミット」を作成するのは非常に簡単です。ファイルと識別子の名前を変更するのは非常に簡単です。
マイナス：歴史の概念はありません---8月5日の状態を回復することはできません。darcsを使用して以前のバージョンに戻す方法を実際に理解したことはありません。
ディールブレーカー：darcsはスケーリングしません。私（および他の多くの人）は、darcsを使用するGHCで大きな問題に直面しました。3か月分の変更を取り込もうとして、9日間100％のCPU使用率でハングアップしました。去年の夏、darcsを機能させるために2週間を失い、最終的にすべての変更を手作業で元のリポジトリに再生するという悪い経験をしました。
結論：趣味のプロジェクトのために自分の足を撃たないようにするためのシンプルで軽量な方法が必要な場合は、darcsが最適です。しかし、darcs 2で対処されたパフォーマンスの問題のいくつかがあっても、それはまだ産業用強度のものではありません。自慢の「パッチの理論」がいくつかの方程式といくつかの素敵な写真よりも少し多いものになるまで、私は実際にdarcsを信じません。査読付きの会場で発表された実際の理論を見たいです。過去の時間です。
組み込みシステム開発用の Sun ワークステーションをオフにする前は、Sun のTeamWareソリューションを使用していました。TeamWare は、SCCS をローカル リポジトリ ファイル リビジョン システムとして使用する完全な分散ソリューションであり、多数の可能性がある集中型リポジトリへのマージ操作 (ブランチの名前変更によって実行) を処理する一連のツールを備えたラッパーです。実際、これは分散されているため、マスター リポジトリ自体は存在せず (必要な場合の規則を除いて)、すべてのユーザーがソース ツリー全体とリビジョンの独自のコピーを持っています。「プットバック」操作では、3 方向差分を使用するマージ ツールがアルゴリズムを使用して何が何であるかを分類し、時間をかけて蓄積されたさまざまな開発者からの変更を組み合わせることができます。
開発プラットフォームを Windows に切り替えた後、最終的にAccuRevに切り替えました。AccuRev は集中型サーバーに依存しているため、真の分散型ソリューションではありませんが、論理的にはワークフロー モデルからは非常に近いものになります。TeamWare では、すべてのファイルのすべてのリビジョンを含め、すべてのファイルの完全に個別のコピーが各クライアントに存在していましたが、AccuRev の下では、これは中央データベースで維持され、ローカル クライアント マシンには、ローカルで編集するためのフラット ファイルの最新バージョンしかありません。ただし、これらのローカル コピーは、サーバーへのクライアント接続を介してバージョン管理され、他の開発者によって暗黙的に作成された他の変更 (つまり、ブランチ) とは完全に個別に追跡できます。
個人的には、TeamWare によって実装された分散モデルまたは AccuRev によって実装された一種のハイブリッド モデルは、完全に集中化されたソリューションよりも優れていると思います。これの主な理由は、ファイルをチェックアウトしなければならない、または別のユーザーがファイルをロックしているという概念がないためです。また、ユーザーはブランチを作成または定義する必要はありません。ツールは暗黙的にこれを行います。大規模なチームや、ソース ファイルのセットに貢献または維持している別のチームがある場合、これにより、"ツールによって生成された" ロックに関連する衝突が解決され、最終的に変更を調整する必要がある開発者レベルでコードの変更をより調整できるようになります。ある意味では、分散モデルは、集中型モデルによって設定された粒度の粗いロックよりも、はるかに粒度の細かい「ロック」を可能にします。
職場の私のグループは Git を使用しており、それが世界を大きく変えています。私たちは、SCCS と大量の csh スクリプトを使用して、非常に大規模で複雑なプロジェクトを管理し、それらの間でコードを共有していました (とにかく試みました)。
Git では、サブモジュールのサポートにより、この作業の多くが簡単になり、最小限のスクリプトしか必要ありません。ブランチは保守と追跡が簡単なので、私たちのリリース エンジニアリングの取り組みは大幅に縮小されました。コストを抑えてブランチとマージを実行できるようになったことで、複数のプロジェクト (コントラクト) にわたって単一のソース コレクションを維持することがかなり簡単になりました。また、Git のスクリプト可能性は大きな利点であることがわかりました。これは、フックまたはスクリプトを実行することでその動作をカスタマイズできるため. git-sh-setupです。
また、分散したネットワーク化されていないサイト (この場合は、切断された安全なラボ) 全体でバージョン管理を維持する必要がある場合もあります。パッチなど）。
これの一部は、80 年代初頭から一歩踏み出し、最新のバージョン管理メカニズムを採用したことによるものですが、Git はほとんどの領域で「正しく機能しました」。
あなたが探している答えの範囲はわかりませんが、Git での経験は非常にポジティブなものです。
私は Git が大好きで、特に GitHub が大好きです。ローカルでコミットしてロールバックできるのはとてもいいことです。また、チェリー ピック マージは、些細なことではありませんが、それほど難しくなく、Svn や CVS が実行できるものよりもはるかに高度です。
私はしばらくの間バザールを使用していて、それが大好きです。些細な分岐とマージバックにより、分岐を使用する必要があるため、分岐を使用することに大きな自信があります。（中央のvcsツールでこれを許可する必要があることはわかっていますが、Subversionを含む一般的なツールではこれを簡単に許可しません）。
bzrは、集中型リポジトリとして機能することから完全に分散されることまで、ソロから完全に分散されるまで、かなりの数の異なるワークフローをサポートします。各ブランチ（開発者または機能用）を個別にマージできるため、コードレビューはブランチごとに実行できます。
bzrには、Subversionリポジトリを操作できる優れたプラグイン（bzr-svn ）もあります。svnリポジトリのコピーを作成できます（ローカルリポジトリの履歴全体をフェッチするため、最初はしばらく時間がかかります）。その後、さまざまな機能のブランチを作成できます。機能の途中でトランクをすばやく修正したい場合は、追加のブランチを作成してそこで作業し、トランクにマージして、半分完了した機能をそのままにしてトランクの外に置くことができます。素晴らしい。これまでのところ、破壊に対抗することが私の主な用途です。
注私はLinuxでのみ使用しており、ほとんどの場合コマンドラインから使用していますが、他のプラットフォームでも正常に機能することを目的としており、TortoiseBZRなどのGUIがあり、 IDEなどとの統合について多くの作業が行われています。
私は自分の家のプロジェクトのためにMercurialで遊んでいます。これまでのところ、私が気に入っているのは、複数のリポジトリを持つことができることです。ラップトップをキャビンに持って行っても、自宅でCVSを実行したときとは異なり、バージョン管理は可能です。分岐はhg cloneクローンと同じくらい簡単で、作業できます。
Subversion を SourceForge やその他のサーバーで使用し、中規模のチームとさまざまな接続を行っていますが、非常にうまく機能しています。
私は多くの理由から集中型ソース管理の強力な支持者ですが、あるプロジェクトで BitKeeper を簡単に試してみました。おそらく、何年にもわたって何らかの形式 (Perforce、Subversion、CVS) で集中型モデルを使用してきた結果、分散ソース管理が使いにくいことに気付きました。
私は、私たちのツールが実際の作業の邪魔になるようなことがあってはならないと考えています。彼らは仕事をより簡単にするはずです。それで、頭がドキドキする経験を何度かした後、私は救い出しました。このモデルは、ほとんどの開発者が SCM の世界でおそらく慣れ親しんでいるものとは大きく異なるため、ボートを揺るがす前にチームで非常に厳しいテストを行うことをお勧めします。
darcs 2.1.0 を使用しており、私のプロジェクトには最適です。使いやすい。チェリーピッキングの変化が大好きです。
私は同僚の 1 人と一緒に仕事で Git を使用しています。ただし、メインのリポジトリは SVN です。ワークステーションを頻繁に切り替える必要がありますが、Git を使用すると、別のマシンのローカル リポジトリから変更を簡単に取得できます。チームとして同じ機能に取り組んでいるとき、作業を簡単にマージできます。
git-svn ブリッジは、SVN にチェックインするときに、すべてのコミットを書き換えて git-svn-id コメントを追加するため、少し不安定です。これは、私の同僚のレポと私の間のマージの素晴らしい歴史を破壊します。すべてのチーム メンバーが Git を使用しているとしたら、中央リポジトリをまったく使用しないだろうと予測しています。
開発しているOSについてはおっしゃっていませんでしたが、Gitにはすべての機能を利用するためにコマンドラインを使わなければならないという欠点があります。Gitk はマージ履歴を視覚化するための優れた GUI ですが、マージ自体は手動で行う必要があります。Git-Gui と Visual Studio プラグインはまだそれほど洗練されていません。
マルチサイトと切断されたシナリオの両方で、分散バージョン管理 ( Plastic SCM ) を使用します。
1- マルチサイト: 離れた場所にいるグループがある場合、インターネット接続が信頼できない場合や、速度が不十分で開発者の作業が遅くなることがあります。次に、同期できる独立したサーバー（プラスチックはブランチを前後に複製します）を持つことは非常に便利で、物事をスピードアップします。企業のほとんどは、各開発者が独自のレプリケートされたリポジトリを持つ「完全に分散された」慣行に依然として関心を持っているため、これはおそらく企業にとって最も一般的なシナリオの 1 つです。
2- 切断された (または、必要に応じて完全に分散された): すべての開発者は、ピアまたは中央の場所との間で相互に複製される独自のリポジトリを持っています。リモートの「中央」にアクセスすることなく、顧客の場所に行ったり、ラップトップを持って家に帰ったりして、ブランチを切り替えたり、コードをチェックアウトおよびチェックインしたり、履歴を確認したり、注釈を実行したりできるのは非常に便利です。サーバ。その後、オフィスに戻るたびに、数回クリックするだけで変更 (通常はブランチ) を複製するだけです。
Subversion の使用
Subversion は配布されていないので、私が話していることがわからない場合に備えて、ウィキペディアのリンクが必要だと思います :)