分散バージョン管理を使用していますか?

https://stackoverflow.com/questions/26845

09-06-2019
|

質問

分散バージョン管理 (分散リビジョン管理、分散バージョン管理とも呼ばれます) を使用している人々と、それをどのように見つけているのかを聞きたいです。Mercurial、Darcs、Git、Bazaar、何を使っていますか?まだ使っていますか？過去にクライアント/サーバー RCS を使用したことがある場合、それが優れていると感じていますか、悪いと感じていますか、あるいは単に違うと感じていますか?何を言えば私も時流に乗れるでしょうか?あるいは飛び降りてもいいですし、ネガティブな経験をした人たちの意見も聞きたいです。

現在、現在のソース管理システム (Subversion) を置き換えることを検討しています。これがこの質問のきっかけです。

特に、マシンの電源が同時に入っていない可能性があり、接続が非常に遅い他の国の同僚と一緒にこの製品を使用したことがある方に興味があります。

分散バージョン管理が何なのかわからない場合は、次のいくつかの記事を参照してください。

分散バージョン管理の概要

ウィキペディアの項目

解決

私は仕事でも個人的なプロジェクトでも Mercurial を使用してきましたが、本当に満足しています。私が考える利点は次のとおりです。

ローカルのバージョン管理。 時々、何かに取り組んでいて、そのバージョン履歴を保持したいことがありますが、それを中央リポジトリにプッシュする準備ができていません。分散 VCS を使用すると、準備が整うまで分岐せずにローカルリポジトリにコミットするだけです。そうすれば、他の人が私に必要な変更を加えた場合でも、それを取得して自分のコードに統合できます。準備ができたら、サーバーにプッシュします。
マージ競合が少なくなります。 これらは今でも発生しますが、頻度は低くなり、リスクも少なくなっているようです。すべてのコードがローカルリポジトリにチェックインされているため、マージに失敗した場合でも、いつでもバックアップしてやり直すことができるからです。
リポジトリをブランチとして分離します。 いくつかの開発ベクターを同時に実行している場合は、リポジトリのクローンをいくつか作成して、各機能を個別に開発できます。そうすれば、何かが壊れたり滑ったりしても、破片を取り出す必要がありません。準備ができたら、それらを結合するだけです。
スピード。 Mercurial は、一般的な操作のほとんどがローカルで行われるため、操作がはるかに高速です。

もちろん、他の新しいシステムと同様に、移行中にはある程度の痛みが伴いました。SVN を使用していたときとは異なる方法でバージョン管理について考える必要がありますが、全体的には、それだけの価値は非常にあると思います。

他のヒント

私が働いている場所では、(git と mercurial を評価した後) SVN から Bazaar に移行することにしました。Bazaar は簡単なコマンドで簡単に始めることができました (git の 140 個のコマンドとは異なります)。

私たちが認識している利点は、ローカルブランチを作成し、メインバージョンに影響を与えることなく作業できることです。また、ネットワークにアクセスせずに作業できるため、差分実行も高速になります。

私が気に入っている bzr のコマンドの 1 つは shelve 拡張機能です。1 つのファイル内の 2 つの論理的に異なるコードの作業を開始し、1 つの部分だけをコミットしたい場合は、shelve 拡張機能を使用して、後で他の変更を文字通りシェルブすることができます。Git では、インデックス (ステージング領域) で同じことを行うことができますが、bzr の UI はより優れています。

ほとんどの人は、コミットとプッシュ (bzr ci + bzr Push) の 2 つのコマンドを入力する必要があるため、移行することに消極的でした。また、ブランチとマージの概念を理解することも困難でした (誰もブランチを使用したり、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 を使用している場合。優れた履歴視覚化ツールがあれば役立つでしょうが、私は利用可能なツールにまだ満足していません。

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 つの方法があります。

私は同僚とサーバーを共有しており、プロジェクトのメインリポジトリを保持しています。
私が取り組んでいる OSS プロジェクトでは、Mercurial を使用して作業のパッチを作成し (hg エクスポート)、プロジェクトのメンテナーはそれをリポジトリに適用するだけです (hg インポート)。

非常に簡単に操作できますが、非常に強力です。しかし、一般的に、VSC の選択はプロジェクトのニーズによって異なります。

組み込みシステム開発のために Sun ワークステーションをオフにする前は、Sun のワークステーションを使用していました。チームウェア解決。TeamWare は、SCCS をローカルリポジトリファイルリビジョンシステムとして使用し、(ブランチの名前変更を通じて行われる) マージ操作を処理する一連のツールを使用して、多数ある集中リポジトリに戻す完全な分散ソリューションです。実際、分散されているため、マスターリポジトリ自体は実際には存在せず (必要な場合は例外として)、すべてのユーザーがソースツリー全体とリビジョンの独自のコピーを持っています。「元に戻す」操作中に、3 方向の差分を使用するマージツールがアルゴリズム的に何が何であるかを分類し、時間の経過とともに蓄積されたさまざまな開発者による変更を結合できるようにします。

開発プラットフォームを Windows に切り替えた後、最終的にはアキュレブ. 。AccuRev は集中サーバーに依存しているため、真の分散ソリューションではありませんが、ワークフローモデルから論理的には非常に近いものになります。TeamWare では、すべてのファイルのすべてのリビジョンを含め、すべてのコピーが各クライアントに完全に個別に存在していましたが、AccuRev ではこれが中央データベースに維持され、ローカルクライアントマシンにはローカルで編集できるフラットファイルの現在のバージョンのみが存在します。ただし、これらのローカルコピーは、サーバーへのクライアント接続を通じてバージョン管理でき、他の変更とは完全に分けて追跡できます (例:ブランチ) 他の開発者によって暗黙的に作成された

個人的には、TeamWare によって実装された分散モデル、または AccuRev によって実装された一種のハイブリッドモデルの方が、完全に集中化されたソリューションよりも優れていると思います。その主な理由は、ファイルをチェックアウトする必要がある、または別のユーザーによってファイルがロックされているという概念がないことです。また、ユーザーはブランチを作成したり定義したりする必要はありません。ツールはこれを暗黙的に実行します。ソースファイルのセットに貢献または維持する大規模なチームまたは異なるチームが存在する場合、これにより「ツールで生成された」ロック関連の衝突が解決され、最終的に変更を調整する必要がある開発者レベルでコードの変更をより調整できるようになります。ある意味、分散モデルでは、集中型モデルによって確立される粗い粒度のロックではなく、より粒度の細かい「ロック」が可能になります。

大規模プロジェクト (GHC) および多くの小規模プロジェクトで darcs を使用してきました。私はダルクに対して愛憎の関係を持っています。

プラス:リポジトリのセットアップが驚くほど簡単です。リポジトリ間で変更を移動するのは非常に簡単です。別のリポジトリで「ブランチ」を複製して試すのは非常に簡単です。一貫した小さなグループで「コミット」するのは非常に簡単で、それは理にかなっています。ファイルと識別子の名前を変更するのは非常に簡単です。

マイナス点:歴史の概念がないので、「8 月 5 日の状態」を取り戻すことはできません。darcs を使用して以前のバージョンに戻す方法がまったく分かりません。

合意を壊すもの：darcs はスケールしません。私（そして他の多くの人）は、GHC が darcs を使用していることで大きなトラブルに巻き込まれました。3か月分の変化を引き付けようとして、9日間100％のCPU使用でハングアップしました。昨年の夏、私は悪い経験をしました。そこでは、DARCSの機能を試みようとして2週間を失い、最終的にはすべての変更を手作業で手付かずのリポジトリにリプレイすることに頼りました。

結論：darcs は、趣味のプロジェクトで失敗しないようにするためのシンプルで軽量な方法が必要な場合に最適です。しかし、darcs 2 ではいくつかのパフォーマンスの問題が解決されていますが、それでも産業用の強度を備えたものではありません。私は、自慢の「パッチ理論」がいくつかの方程式といくつかの素敵な写真以上のものになるまで、ダルクを本当に信じるつもりはありません。本物の理論が査読付きの場で発表されるのを見たい。もう時間は過ぎた。

私は Git、特に GitHub が大好きです。ローカルでコミットとロールバックができるのはとても便利です。また、マージの厳選は簡単ではありませんが、それほど難しいものではなく、Svn や CVS が実行できるものよりもはるかに高度です。

私の職場のグループは Git を使用していますが、それは世界を大きく変えています。私たちは、SCCS と大量の csh スクリプトを使用して、プロジェクト間でコードを共有する (とにかく試みた) 非常に大規模で複雑なプロジェクトを管理していました。

Git では、サブモジュールのサポートにより、この作業の多くが簡単になり、最小限のスクリプトのみが必要になります。ブランチの保守と追跡が簡単なため、私たちのリリースエンジニアリングの取り組みは大幅に短縮されました。分岐とマージを低コストで実行できるため、複数のプロジェクト (コントラクト) にわたって単一のソースコレクションを維持することが非常に簡単になります。一方、以前は、典型的な流れを中断すると非常にコストがかかりました。また、Git のスクリプト化可能性は、 巨大な さらに、フックまたはスクリプトを通じてその動作をカスタマイズできるため、 . git-sh-setup, そして、以前のようにだらだらの山のようには見えません。

また、ネットワークに接続されていない分散サイト (この場合は、接続されていない安全なラボ) 全体でバージョン管理を維持する必要がある状況も時々ありますが、Git にはそれを非常にスムーズに処理するためのメカニズム (バンドル、基本的なクローンメカニズム、フォーマットされたもの) が備わっています。パッチなど）。

これには、80 年代初頭から抜け出し、最新のバージョン管理メカニズムを採用しただけの部分もありますが、Git はほとんどの領域で「正しく機能しました」。

あなたが求めている答えの範囲はわかりませんが、Git に関する私たちの経験は非常に肯定的でした。

中規模のチームとさまざまな接続を介して Subversion を SourceForge やその他のサーバーとともに使用しており、非常にうまく機能しています。

私はさまざまな理由から集中ソース管理を強く支持していますが、プロジェクトで BitKeeper を簡単に試してみました。おそらく、何年も何らかの形式 (Perforce、Subversion、CVS) で集中型モデルを使用してきた後、分散ソース管理は使いにくいと感じたのでしょう。

私は、私たちのツールが実際の作業の邪魔をしてはならないという考えを持っています。仕事が楽になるはずです。それで、何度か頭が痛くなるような経験をした後、私は逃げました。このモデルは、SCM の世界でおそらくほとんどの開発者が慣れ親しんでいるものとは大きく異なるため、本腰を入れる前にチームで非常に厳しいテストを行うことをお勧めします。

使ったことがあるバザール今は少しの間、気に入っています。簡単な分岐とマージによって、ブランチを使用すべきとおりに使用することに大きな自信が得られます。(中央の vcs ツールでこれが許可されるはずであることはわかっていますが、subversion を含む一般的なツールではこれが簡単に許可されません)。

bzr はかなり多くの異なるものをサポートしていますワークフロー単独から、集中リポジトリとしての動作を経て、完全に分散されたものまで。各ブランチ (開発者または機能用) を個別にマージできるため、ブランチごとにコードレビューを行うことができます。

bzr には素晴らしいプラグインもあります (bzr-svn) Subversion リポジトリを操作できるようになります。svn リポジトリのコピーを作成できます (ローカルリポジトリの履歴全体を取得するため、最初はしばらく時間がかかります)。その後、さまざまな機能の分岐を作成できます。機能の途中でトランクを簡単に修正したい場合は、追加のブランチを作成してそこで作業し、その後トランクにマージして、途中で完成した機能をそのままにしてトランクの外に残すことができます。素晴らしい。これまでのところ、破壊活動に対抗することが私の主な用途です。

私はこれを Linux でのみ使用しており、主にコマンドラインから使用していますが、他のプラットフォームでもうまく動作するように意図されており、次のような GUI があることに注意してください。トータスBZR との統合に関して多くの作業が行われています。 IDE など。

自宅のプロジェクトで Mercurial を使って遊んでいます。今のところ、私が気に入っているのは、複数のリポジトリを持てることです。自宅で CVS を実行していたときとは異なり、ラップトップを機内に持っていってもバージョン管理が可能です。分岐は次のように簡単です hg clone そしてクローンの開発に取り組んでいます。

Subversion の使用

Subversion は配布されていないので、私が何を言っているのかわからない人に備えて wikipedia へのリンクが必要だと思います :)

darcs 2.1.0 を使用していますが、私のプロジェクトには最適です。使いやすい。チェリーピッキングの変化が大好きです。

私は同僚の 1 人と仕事で Git を使用しています。ただし、メインのリポジトリは SVN です。ワークステーションを切り替える必要があることはよくありますが、Git を使用すると、別のマシン上のローカルリポジトリから変更を取得するだけで非常に簡単になります。チームとして同じ機能に取り組んでいる場合、作業を簡単にマージできます。

git-svn ブリッジは、SVN にチェックインするときに、すべてのコミットを書き換えて git-svn-id コメントを追加するため、少し不安定です。これにより、同僚のリポジトリと鉱山間のマージの素晴らしい歴史が破壊されます。すべてのチームメンバーが Git を使用するのであれば、中央リポジトリはまったく使用しないだろうと私は予想します。

どの OS で開発しているかは明言されませんでしたが、Git にはすべての機能を利用するにはコマンドラインを使用しなければならないという欠点があります。Gitk はマージ履歴を視覚化するための優れた GUI ですが、マージ自体は手動で行う必要があります。Git-Gui と Visual Studio プラグインはまだそれほど洗練されていません。

私たちは分散バージョン管理を使用しています (プラスチックSCM) マルチサイトと切断されたシナリオの両方に対応します。

1- マルチサイト:離れた場所にグループがある場合、インターネット接続に依存できなかったり、速度が十分ではなく開発者の速度が低下したりすることがあります。次に、逆に同期できる独立したサーバー (プラスチックはブランチを前後に複製します) があると非常に便利で、処理が高速化されます。これはおそらく、企業にとって最も一般的なシナリオの 1 つです。企業のほとんどは依然として、各開発者が独自の複製リポジトリを持つ「完全分散」の実践に懸念を抱いているからです。

2- 切断されている (または必要に応じて完全に分散されている):すべての開発者は独自のリポジトリを持ち、他の開発者または中央の場所との間で複製されます。顧客の場所に行ったり、ラップトップを持って帰宅したりするときに、リモートの「セントラル」にアクセスすることなく、引き続きブランチの切り替え、コードのチェックアウトとチェックイン、履歴の確認、注釈の実行などができるのは非常に便利です。サーバ。その後、オフィスに戻るたびに、数回クリックするだけで変更内容 (通常はブランチ) を複製するだけです。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow