企業においてフリーソフト／オープンソースソフトを導入しようとすると，以下のような意見に反対されることがあるのではないでしょうか？

大規模開発では使えないんでしょ？

そこで今回は，大規模開発における構成管理を効率よく運用するための，Mercurialのリポジトリ分散性を活かした，幾つかのアイディアについて説明したいと思います。

中央集約形式の問題

ある程度以上の規模の開発の場合，事前に（あるいは開発を進めながら）取り決めたI/Fを介して連携する複数の部位に全体を分割し，複数のチームがそれぞれの担当分を開発する，という進め方をするのが一般的です。

このような開発体制を採用した場合，単一サーバが全ての要求を受け付ける中央集約形式のCVSやSubversionでは，サーバの応答性能低下が懸念されます。

また，全ての開発者が同様にメイントランクにアクセスしていたのでは，他拠点の開発成果とのマージが頻発しますので，拠点ごとにブランチを作成するなどの必要性が出てきます。

しかし，各ブランチ毎のアクセスを制限する方法がありませんから，他拠点成果との混交やメイントランクへのコミットが，誤操作等によって発生する危険が残ります。

この問題はリリースにおける成果混交と同じで，単にメンバー全員の習熟度を一定水準以上に保つだけ（開発体制が大きくなると，保つだけでも思いのほか難しいものですが）では解決しません。

ここで，各拠点ごとのリポジトリと，成果集約用のリポジトリに分離したとします。

しかし，リポジトリ間で作業成果を行き来させた際には，履歴等の構成管理情報が失われてしまいます。

各拠点での履歴などは必要ない

という場合もあるでしょうが，参照しない(do not)ことと，参照できない(can not)ことは全くの別物です。