Clearcase から別の VCS (おそらく SVN または Mercurial) に移行しています。この移行を行った企業は、別の VCS ツールを選択する際に重要だと感じた要因は何ですか?また、移行を容易にしたのはどのようなプラクティスでしたか?
7 に答える
SVN と Mercurial はどちらも優れた SCM です。多くのオープンソース プロジェクトで使用されています。選択がこれら 2 つだけに絞られた場合、あなたとあなたのチームが考慮しなければならないことは次のとおりです。
ワークフローとワークフロー
コミットと分岐をどのように行いたいですか? 分散型か純粋集中型か? これは会社の方針にも関係しています。すべてを集中管理したい場合は、SVN を使用してください。しかし、これは Mercurial で中央リポジトリを持てないという意味ではありません。チームが Mercurial のような DVCS を選択すると、次の理由から非常に有益です。
- 誰もが独自のローカル コピーを持っています。これにより、彼らは自宅で作業し、ローカル コミットを行うことができます。
- 誰でも自分のローカル マシンでローカル ブランチを実行できます。リビジョン間のマージについて心配する必要はありません。Mercurial はマージを適切にサポートしており、SVN に比べて比較的簡単です。
- 他の開発者のマシンからリビジョンをプルするゲートキーパーに誰かを任命できるため、全員がコミット アクセス権を持っている必要はありません。これにより、コードを中央リポジトリに送信する前にコード レビューを行うことができます。
それ以外は、どちらも優れた (十分な) パフォーマンス、優れた Windows サポート ( SVN、Hg )、優れたドキュメント/書籍 ( SVN、Hg ) を備えているため、どちらも非常に優れています。
追加するカップルは次のとおりです。
- パフォーマンス: 遅い開発ツールは開発者の思考プロセスを妨害します
- パワー (機能性): マージはどれくらい良いですか? git のような新しいツールは、CVS や SVN などの古いスタイルのツールよりもはるかに優れたマージ サポートと追跡を備えています。Git には、開発プロセスを高速化する bisect などの非常に便利なツールも用意されています。
- コミュニティ サポート: ツールはどの程度広く受け入れられていますか? 5年後に傍観者になるものを選びたくありません。
一般的に、私は常に分散バージョン管理システム (DVCS) を使用します。私はmercurialではなくgitを試しました。しかし、ここでの前提は同じです。
集中型システムを使用すると、その構造に縛られます。分散システムを使用している場合はそうではありません。ただし、配布できるからといって、配布する必要はありません。チーム内で単一の中央リポジトリを持つ方が理にかなっている場合は、そのようにしてください。
過小評価してはならないのは、地方支店の力です。集中型システムでの分岐はかなり面倒で、開発者や機能の分岐はめったに行われません。開発者は、複数の作業コピーを持つか、安全でない変更を作業コピーに保持して、ビルドを壊さないようにします。分散型システムでは、開発者がローカル ブランチを作成し、その上で動作します。ショー ストッパー バグによって中断された彼は、master ブランチに戻って問題を修正し、変更を中央リポジトリにプッシュして、機能ブランチに戻します。ワークフローは非常にスムーズです。
さらに、システムの分散型の性質により、システムは堅牢になります。サーバーがダウンした場合、開発者にとっては通常どおりのビジネスであり、変更を相互に交換することさえできます。
最後に、開発者は飛行機、電車、または好きな場所で仕事を家に持ち帰ることができます。VCS 機能を失うことはなく、適切なコミットを行うことができます。
その結果、VCS に関する開発者の行動は、テクノロジではなく会社のポリシーによって定義され、ポリシーはいつでも変更できます。
古き良き Clearcase から移行する場合は ;-) Plastic SCM を簡単に見てみましょう。基本的な概念のほとんどはまだそこにありますが、面倒な部分はすべてなくなりました。そして配布です。次のリンクを確認してください: http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html
これは古いスレッドですが、少し貢献したかったのです。IMO、SVNはコースを実行しました。公平を期すために、約 50 人ほどのユーザーがいて、多くの分岐を行わない場合、確かに、CC よりも悪いことにはなりません。ただし、CC は古くて複雑ですが、まだ多くの成熟した機能を備えています。したがって、成熟した CC ショップの場合、SVN はニーズを満たしていません。実際、ベスト プラクティスは分岐を減らし、主幹から離れることです。したがって、(上記の選択肢を考えると) より良い選択は Hg です。また、私はdvcsに偏っています。真の dvcs です...そして OSS の選択肢は Hg と git の 2 つだけです。現在、商用システムの 1 つ、プラスチック scm があります。ファイル履歴の視覚的表現に慣れている場合 (vtree ブラウザー、または CC UCM のコンポーネント ツリー ブラウザー、それが呼ばれていたと思います)、プラスチックはより実行可能な選択肢かもしれません。私が見たように、グラフィカルなvtreeと、ブランチツリーエクスプローラーのような何かがあります。私たちの多くが交代でホワイトボード上で「プロセス」モデルを作成する CC をサポートしたことを覚えています。プラスチックにはそれが組み込まれています。とにかく、私は dvcs に偏っています... 私は svn と cc で十分に苦しみ、高価なレプリケーション ツールとマスターシップ スクリプトを使用しようとしました。dvcs はとてもシンプルです。Linux/Unix の開発に精通している場合は、git の方が適しているかもしれません。より多くのウィンドウまたはミックスがあれば、Hg と Plastic がより良い選択肢のように見えます。プラスチックでより多くのグラフィックスとビジュアル。Hg には、CC で慣れ親しんだ許可とアクセス制御の多くが欠けていると思います。これがお役に立てば幸いです。私が見たように、グラフィカルなvtreeと、ブランチツリーエクスプローラーのような何かがあります。私たちの多くが交代でホワイトボード上で「プロセス」モデルを作成する CC をサポートしたことを覚えています。プラスチックにはそれが組み込まれています。とにかく、私は dvcs に偏っています... 私は svn と cc で十分に苦しみ、高価なレプリケーション ツールとマスターシップ スクリプトを使用しようとしました。dvcs はとてもシンプルです。Linux/Unix の開発に精通している場合は、git の方が適しているかもしれません。より多くのウィンドウまたはミックスがあれば、Hg と Plastic がより良い選択肢のように見えます。プラスチックでより多くのグラフィックスとビジュアル。Hg には、CC で慣れ親しんだ許可とアクセス制御の多くが欠けていると思います。これがお役に立てば幸いです。私が見たように、グラフィカルなvtreeと、ブランチツリーエクスプローラーのような何かがあります。私たちの多くが交代でホワイトボード上で「プロセス」モデルを作成する CC をサポートしたことを覚えています。プラスチックにはそれが組み込まれています。とにかく、私は dvcs に偏っています... 私は svn と cc で十分に苦しみ、高価なレプリケーション ツールとマスターシップ スクリプトを使用しようとしました。dvcs はとてもシンプルです。Linux/Unix の開発に精通している場合は、git の方が適しているかもしれません。より多くのウィンドウまたはミックスがあれば、Hg と Plastic がより良い選択肢のように見えます。プラスチックでより多くのグラフィックスとビジュアル。Hg には、CC で慣れ親しんだ許可とアクセス制御の多くが欠けていると思います。これがお役に立てば幸いです。私たちの多くが交代でホワイトボード上で「プロセス」モデルを作成する CC をサポートしたことを覚えています。プラスチックにはそれが組み込まれています。とにかく、私は dvcs に偏っています... 私は svn と cc で十分に苦しみ、高価なレプリケーション ツールとマスターシップ スクリプトを使用しようとしました。dvcs はとてもシンプルです。Linux/Unix の開発に精通している場合は、git の方が適しているかもしれません。より多くのウィンドウまたはミックスがあれば、Hg と Plastic がより良い選択肢のように見えます。プラスチックでより多くのグラフィックスとビジュアル。Hg には、CC で慣れ親しんだ許可とアクセス制御の多くが欠けていると思います。これがお役に立てば幸いです。私たちの多くが交代でホワイトボード上で「プロセス」モデルを作成する CC をサポートしたことを覚えています。プラスチックにはそれが組み込まれています。とにかく、私は dvcs に偏っています... 私は svn と cc で十分に苦しみ、高価なレプリケーション ツールとマスターシップ スクリプトを使用しようとしました。dvcs はとてもシンプルです。Linux/Unix の開発に精通している場合は、git の方が適しているかもしれません。より多くのウィンドウまたはミックスがあれば、Hg と Plastic がより良い選択肢のように見えます。プラスチックでより多くのグラフィックスとビジュアル。Hg には、CC で慣れ親しんだ許可とアクセス制御の多くが欠けていると思います。これがお役に立てば幸いです。私は svn と cc で十分に苦しみ、高価な複製ツールと mastership スクリプトを使おうとしました。dvcs はとてもシンプルです。Linux/Unix の開発に精通している場合は、git の方が適しているかもしれません。より多くのウィンドウまたはミックスがあれば、Hg と Plastic がより良い選択肢のように見えます。プラスチックでより多くのグラフィックスとビジュアル。Hg には、CC で慣れ親しんだ許可とアクセス制御の多くが欠けていると思います。これがお役に立てば幸いです。私は svn と cc で十分に苦しみ、高価な複製ツールと mastership スクリプトを使おうとしました。dvcs はとてもシンプルです。Linux/Unix の開発に精通している場合は、git の方が適しているかもしれません。より多くのウィンドウまたはミックスがあれば、Hg と Plastic がより良い選択肢のように見えます。プラスチックでより多くのグラフィックスとビジュアル。Hg には、CC で慣れ親しんだ許可とアクセス制御の多くが欠けていると思います。これがお役に立てば幸いです。
サードパーティのサポート。システムには Visual Studio 用の成熟した SCC プロバイダーがありますか? (SVN はい、Hg は成熟していません)。
エクリプス?どちらもサポートが充実しています。
開発者はコマンド ライン コマンドを使用することに慣れていますか? その後、サードパーティのサポート/プラグインは問題にならない場合があります.