大規模な組織でのMercurialの使用
私はしばらくの間、自分の個人的なプロジェクトにMercurialを使用してきましたが、それが大好きです。私の雇用主はCVSからSVNへの切り替えを検討していますが、代わりにMercurial（または他のDVCS）をプッシュする必要があるかどうか疑問に思っています。
Mercurialの1つの問題は、「プロジェクト」ごとに1つのリポジトリを持つという考えに基づいて設計されているように見えることです。この組織では、現在のCVSリポジトリに、階層的に編成された数十の異なる実行可能ファイル、DLL、およびその他のコンポーネントがあります。一般的な再利用可能なコンポーネントはたくさんありますが、一部の顧客固有のコンポーネント、および顧客固有の構成もあります。現在のビルド手順では、通常、CVSリポジトリからサブツリーのセットを取得します。
CVSからMercurialに移行する場合、リポジトリ/リポジトリを整理するための最良の方法は何ですか？すべてを含む1つの巨大なMercurialリポジトリが必要ですか？そうでない場合、小さなリポジトリはどの程度細かくする必要がありますか？さまざまな場所から更新をプルしてプッシュする必要がある場合、人々は非常に煩わしいと思うでしょうが、会社のコードベース全体をプル/プッシュする必要がある場合も、煩わしいと感じるでしょう。
誰かがこれやアドバイスの経験がありますか？
関連する質問：
AFAICS DVCSに対する抵抗のほとんどは、DVCSの使用方法を理解していない人々から来ています。 「中央リポジトリがない」という頻繁に繰り返される声明は、太古の昔からCVS/SVNモデルに閉じ込められており、他に何も想像できない人々にとっては非常に恐ろしいものです。特に、管理職やシニア（経験者および/または皮肉な）強力なソースコードの追跡と再現性を望んでいる開発者（そしておそらく、私がかつて働いていた場所で行ったように、開発プロセスに関する特定の基準を満たす必要がある場合も）。さて、あなたは中央の「祝福された」レポを持つことができます。あなたはそれに縛られていないだけです。たとえば、サブチームがワークステーションの1つに内部プレイグラウンドリポジトリをしばらくの間セットアップするのは簡単です。
ことわざの猫の皮を剥ぐ方法はたくさんあるので、座ってワークフローについて慎重に考えるとお金がかかります。あなたの現在の慣行と、ほぼ無料のクローン作成と分岐があなたに与える力について考えてください。あなたが現在行っていることのいくつかは、CVSタイプのモデルの制限を回避するために進化した可能性があります。型を壊す準備をしてください。移行を通じて全員を楽にするために、おそらくチャンピオンを1人か2人任命する必要があります。大規模なチームでは、コミットアクセスをblessedに制限することを検討する必要があります。
私の仕事（小さなソフトウェアハウス）では、CVSからhgに移行しましたが、元に戻りませんでした。私たちはそれをほとんど一元化された方法で使用しています。メインの（古代の非常に大きな）リポジトリを変換するのは苦痛でしたが、それはどのように行ってもかまいません。それが完了すると、後でVCSを変更するのがはるかに簡単になります。 （CVS変換ツールが何が起こったのか理解できない状況、誰かのコミットが部分的にしか成功せず、何日も気付かなかった状況、ベンダーブランチの解決、時間によって引き起こされた一般的な狂気と狂気が起こっているように見える状況がいくつか見つかりました。後方、異なるタイムゾーンからの現地時間でのタイムスタンプのコミットには助けられません...）
DVCSの大きな利点は、早期にコミットして頻繁にコミットし、準備ができたときにのみプッシュできることです。進行中のさまざまなマイルストーンに到達したら、必要に応じて巻き戻すことができる場所を確保するために、砂に線を引くのが好きですが、これらは明らかに不完全であるため、チームに公開する必要があるコミットではありません。無数の方法で。 （私は主にMercurialキューを使用してこれを行います。）ワークフローがすべてです。私はCVSでこれを行うことはできなかったでしょう。
あなたはすでにこれを知っていると思いますが、CVSから離れることを考えているなら、SVNよりもはるかにうまくいくことができます...
モノリスに、またはモジュールに？パラダイムシフトは、分散されているかどうかに関係なく、使用するVCSに関係なく注意が必要です。 CVSモデルは、レポの残りの部分が最新であるかどうかをチェックせずにファイルごとにコミットできるという点で非常に特別です（モジュールエイリアスが引き起こすことが知られている頭痛の種は言うまでもありません）。
- モノリシックリポジトリの処理はかなり遅くなる可能性があります。 vcsクライアントは、単一のモジュールではなく、ユニバース全体のコピーをスキャンして変更を確認する必要があります。 （Linuxで作業している場合、まだ行っていない場合は、hg inotify拡張機能を調べてください。）
- モノリシックレポは、コミット（プッシュ）時に不要な競合状態も引き起こします。これはCVSの最新のチェックに似ていますが、リポジトリ全体に適用されます。アクティブな開発者が多く、頻繁にコミットしている場合、これはあなたを悩ませます。
モノリシックから遠ざけることは努力する価値があることをお勧めしますが、ビルドシステムの複雑さが増すという点で、独自のオーバーヘッドが発生することに注意してください。 （補足：面倒な雑用を見つけた場合は、それを自動化してください！結局のところ、私たちプログラマーは怠惰な生き物です。）リポジトリをすべてのコンポーネントモジュールに分割するのは極端すぎるかもしれません。少数のリポジトリに関連するコンポーネントがグループ化された中間の家が見つかる場合があります。 Mercurialのサブモジュールのサポート-- ネストされたリポジトリ と フォレスト拡張 （どちらも頭を悩ませるべきです）を調べると便利な場合もあります。
以前の職場では、かなり管理されたメタ構造を持つ独立したCVSモジュールとして保持されていた数十のコンポーネントがありました。コンポーネントは、それらが何に依存し、どのビルドパーツをどこにエクスポートするかを宣言しました。ビルドシステムは自動的にmakeフラグメントを書き込んで、作業中のものが必要なものを取得できるようにします。それは一般的に非常にうまく機能し、CVSの最新のチェックに失敗することは非常にまれでした。 （依存関係の解決に対して最小限の労力で、非常に複雑ですが非常に強力なビルドボットもありました。要件を満たすコンポーネントが既に存在する場合、コンポーネントは再構築されません。インストーラーと全体をアセンブルしたメタコンポーネントに追加してください。 ISOイメージ、そしてあなたは簡単な最初から最後までのビルドとソーサラー見習いに行くための良いレシピを持っています。誰かがそれについて本を書くべきです...）
開示：これは、gitを中心とした別のスレッドからの クロスポスト ですが、とにかくMercurialをお勧めすることになりました。一般的にエンタープライズコンテキストでDVCSを扱っているので、クロスポストで問題ないことを願っています。この質問に合うように少し変更しました。
一般的な意見に反して、DVCSを使用すると、非常に柔軟なワークフローが可能になるため、企業環境では理想的な選択肢だと思います。最初にDVCSとCVCSの使用について説明し、次にベストプラクティスについて説明し、次に特にgitについて説明します。
エンタープライズコンテキストでのDVCSとCVCS：
ここでは一般的な長所/短所については説明しませんが、コンテキストに焦点を当てます。 DVCSを使用するには、集中型システムを使用するよりも規律のあるチームが必要であるというのが一般的な概念です。これは、集中型システムがワークフローを実施する簡単な方法を提供するためです。分散型システムを使用するには、より多くのコミュニケーションと規律が必要です。確立された慣習に固執する。これはオーバーヘッドを誘発するように見えるかもしれませんが、それを良いプロセスにするために必要なコミュニケーションの増加には利点があると思います。チームは、コード、変更、およびプロジェクトのステータス全般について連絡する必要があります。
規律の文脈における別の側面は、分岐と実験を奨励することです。これはMartinFowlersの最近のblikiエントリからの引用です バージョン管理ツール上 、彼はこの現象の非常に簡潔な説明を見つけました。
DVCSは、実験のための迅速な分岐を推奨します。 Subversionでブランチを作成することはできますが、それらがすべての人に表示されるという事実は、人々が実験的な作業のためにブランチを開くことを思いとどまらせます。同様に、DVCSは、作業のチェックポイントを推奨します。つまり、コンパイルもテストにも合格しない可能性のある不完全な変更をローカルリポジトリにコミットします。繰り返しますが、Subversionの開発者ブランチでこれを行うことができますが、そのようなブランチが共有スペースにあるという事実により、人々はそうする可能性が低くなります。
DVCSは、単純なテキストの差分ではなく、有向非巡回グラフ（DAG）でグローバルに一意の識別子を介して変更セットの追跡を提供するため、柔軟なワークフローを可能にします。これにより、チェンジセットの発信元と履歴を透過的に追跡できます。これは非常に重要です。
ワークフロー：
Larry Osterman（Windowsチームで作業しているMicrosoft開発者）は、Windowsチームで採用しているワークフローについて すばらしいブログ投稿 を持っています。最も注目すべきは、次のとおりです。
- クリーンで高品質のコードのみのトランク（マスターリポジトリ）
- すべての開発は機能ブランチで行われます
- 機能チームにはチームリポジトリがあります
- 彼らは定期的に最新のトランクの変更を機能ブランチにマージします（Forward Integrate）
- 完全な機能は、いくつかの品質ゲートを通過する必要があります。レビュー、テストカバレッジ、Q＆A（独自のリポジトリ）
- 機能が完成し、許容できる品質である場合、それはトランクにマージされます（Reverse Integrate）
ご覧のとおり、これらのリポジトリのそれぞれを独自に稼働させることで、さまざまなペースで進んでいるさまざまなチームを切り離すことができます。また、柔軟な品質のゲートシステムを実装する可能性により、DVCSとCVCSが区別されます。このレベルでも権限の問題を解決できます。マスターリポジトリへのアクセスを許可するのはほんの一握りの人だけです。階層のレベルごとに、対応するアクセスポリシーを含む個別のリポジトリを用意します。実際、このアプローチはチームレベルで非常に柔軟です。チームレポをチーム間で共有するかどうか、またはチームリーダーだけがチームレポにコミットできる、より階層的なアプローチが必要かどうかは、各チームに任せる必要があります。
（写真はジョエル・スポルスキーの hginit.com から盗まれました。）
DVCSは優れたマージ機能を提供しますが、これは継続的インテグレーションを使用する代わりになることはありません。その時点でも、トランクリポジトリのCI、チームリポジトリのCI、Q＆Aリポジトリなど、非常に柔軟性があります。
エンタープライズコンテキストでの水銀：
ここでgitvs。hg Flamewarを開始したくありません。あなたは、DVCSへの切り替えを検討することで、すでに正しい方向に進んでいます。 gitの代わりにMercurialを使用する理由は次のとおりです。
- pythonを実行するすべてのプラットフォームがサポートされています
- すべての主要なプラットフォーム（win/linux/OS X）での優れたGUIツール、ファーストクラスのマージ/ vdiffツールの統合
- 非常に一貫性のあるインターフェース、svnユーザーにとって簡単な移行
- Gitが実行できることのほとんどを実行できますが、よりクリーンな抽象化を提供します。危険な操作は常に明示的です。高度な機能は、明示的に有効にする必要がある拡張機能を介して提供されます。
- 商用サポートが利用可能です セレン酸から。
つまり、企業でDVCSを使用する場合、摩擦が最も少ないツールを選択することが重要だと思います。移行を成功させるには、開発者間のスキルの違いを考慮することが特に重要です（VCSに関して）。
最後に指摘したいリソースがいくつかあります。 Joel Spolskyは最近書いた 記事 DVCSに対して提起された多くの議論を打ち負かす。他の人がずっと前にこれらの反論を発見したことは言及されなければなりません。もう1つの優れたリソースは、Eric Sinksブログで、 エンタープライズDVCSの障害 に関する記事を書いています。
まず第一に、巨大なプロジェクトでのDVCSの使用に関する最近の議論が関連しています。
巨大なプロジェクトの分散バージョン管理-それは実行可能ですか？
Mercurialの1つの問題は、「プロジェクト」ごとに1つのリポジトリを持つという考えに基づいて設計されているように見えることです。
はい、Subversionの標準は、複数のプロジェクトを含む1つのモノリシックリポジトリを持つことですが、DVCSでは、コンポーネントごとに1つずつ、より詳細なリポジトリを持つことが望ましいです。 Subversionにはsvn:externalsチェックアウト時に複数のソースツリーを集約する機能（独自のロジスティックおよび技術的な問題があります）。 MercurialとGitの両方に、hgで subrepos と呼ばれる同様の機能があります。
サブリポジトリの考え方は、コンポーネントごとに1つのリポジトリがあり、リリース可能な製品（複数の再利用可能なコンポーネントを含む）は、単にその依存リポジトリを参照するというものです。製品リポジトリのクローンを作成すると、必要なコンポーネントが提供されます。
すべてを含む1つの巨大なMercurialリポジトリが必要ですか？そうでない場合、小さなリポジトリはどの程度細かくする必要がありますか？さまざまな場所から更新をプルしてプッシュする必要がある場合、人々は非常に煩わしいと思うでしょうが、会社のコードベース全体をプル/プッシュする必要がある場合も、煩わしいと感じるでしょう。
モノリシックリポジトリを1つ持つことは確かに可能です（必要に応じて、トラックに分割することもできます）。このアプローチの問題は、リリーススケジュール、およびさまざまなコンポーネントのさまざまなバージョンの管理方法に起因する可能性が高くなります。共通のコンポーネントを共有する独自のリリーススケジュールを持つ複数の製品がある場合は、構成管理を容易にするために、より詳細なアプローチを使用する方がよいでしょう。
注意点の1つは、サブレポのサポートは比較的最近の機能であり、他の機能ほど本格的ではないということです。具体的には、すべてのhgコマンドがサブリポジトリを認識しているわけではありませんが、最も重要なコマンドは認識しています。
テスト変換を実行し、サブレポサポートを試してみたり、製品や依存コンポーネントを整理したりすることをお勧めします。私も同じことを行っている最中です。これが道のりのようです。