MercurialとBitBucketはどちらも、1つの基本的な仮定を行っています。1つのリポジトリ= 1つのプロジェクトです。
多くのプロジェクトで共有される依存関係(ライブラリ)を持つプロジェクトがある場合、この仮定は邪魔になります。現在、複数のプロジェクトにアトミックリビジョンをコミットしながら、プロジェクトごとに個別のBitBucketページを持つことはできなくなりました。
すべてのプロジェクトを1つのリポジトリに入れると、それらはすべてBitBucket上の1つの「プロジェクト」になります。それらを別々のリポジトリに配置すると、依存プロジェクトのリビジョンXで使用されていたライブラリプロジェクトのバージョンを知ることができなくなります。
この状況は通常、BitBucketでどのように解決されますか、またはこの一般的なシナリオに対するサポートは明示的にありませんか?
Mercurialには Subrepositories 機能があり、基本的に他のリポジトリの構成管理を行います。セットアップは非常に簡単です。
次のように。hgsubファイルを作成するだけです。
src/app = https://bitbucket.org/<user>/app
src/framework = https://bitbucket.org/<user>/framework
src/library = https://bitbucket.org/<user>/library
1行に1つのリポジトリ、左側にパス、右側にURL。コミットすると、Mercurialはそれらのリポジトリを取得し、資格情報を要求します。その後、コミットするたびに、。hgsubstateファイルは、サブリポジトリの状態(リビジョン、ブランチ、その他それぞれで選択されています)。
27442cb5903128c6f817e2943030b9297a0d569f src/app
4d11fabc8a6121ceb07e11ddd81fb1e4ad2f5980 src/framework
8d6f570174a535839c189cf84d04f5ae5253a253 src/library
左側はハッシュを表し、右側はリポジトリへのパスを表します。このファイルはバージョン管理されていますが、前述のとおり、Mercurialによって自動的に編集されます。
したがって、src/appでコミットすると、ハッシュが変更されます。各サブリポジトリの状態の組み合わせに満足したら、親リポジトリをコミットします。 * BLAM!*、 構成管理 。
Edit: Hg Guest Repo拡張機能 を発見したばかりで、これが必要なものだと思います、引用:
Extension for enterprises needing to handle modules and components
Hg subrepos do not handle the sharing of components well, due to
the recursive merge from the top (super) repo and requirement to
lock at a specific version.
Guestrepo's goal is to overcome these limitations.
The guestrepo extension does not change any existing Mercurial
behavior. It only adds new commands.
MercurialとBitBucketはどちらも、1つの基本的な仮定を行っています。1つのリポジトリ= 1つのプロジェクトです。
少なくともMercurialの部分については、あなたは間違っていると思います。同じMercurialリポジトリ内に複数のプロジェクトがあり、私(および他の多く)にとって非常にうまく機能しています。
BitBucketに関しては、それはリポジトリーの概念を中心に構築されており、それ以上には進みません。基本的なwikiとバグトラッカーを提供しますが、notはプロジェクト管理ツールです。プロジェクトごとに個別のWikiページが必要な場合は、外部Wikiまたはプロジェクト管理ツールの使用を検討する必要があります。
gitには サブモジュール
hgには subrepository があるように見えます