ライブラリ B と C がプロジェクト A のサブディレクトリでなければならない場合、ライブラリ B を使用するがプロジェクト A とはまったく関係のないプロジェクト D を開始したい場合はどうすればよいですか?
どのプロジェクトも、独立して存在することも、別のプロジェクトのサブリポジトリとして同時に存在することもできます。ワークフローを提案しながら説明します。
まず、各プロジェクト (A、B、C) には、どこかに公開されている祝福されたリポジトリが必要です。

自分のサーバーでhgwebdirを実行するか、 BitbucketやKilnなどの Mercurial ホスティング サービスを利用できます。このようにして、開発者は変更をプル/プッシュするための中央の信頼できるポイントを持ち、バックアップを作成するものがあります。
これらのリポジトリのクローンを作成して、2 つの異なる方法で作業できるようになりました。
プロジェクトを直接クローンします。例えば:
hg clone http://bitbucket.org/LachlanG/LibraryB C:\Lib\LibraryB
のルートに次の内容のファイルを配置して、サブリポジトリの定義を作成します。.hgsub
ProjectA
libraries/libraryB = http://bitbucket.org/LachlanG/LibraryB
libraries/libraryC = http://bitbucket.org/LachlanG/LibraryC
これらのサブリポジトリの定義は、プロジェクト A が複製されるたびに、ライブラリ B とライブラリ C の複製もフォルダに配置する必要があることを Mercurial に伝えlibraries
ます。
プロジェクト A で作業していてコミットすると、libraries/LibraryB
との変更libraries/LibraryC
もコミットされます。Mercurial は、プロジェクト A で使用されているライブラリのバージョンを.hgsubstate
ファイルに記録します。その結果hg update
、先週の動作を確認するために古いバージョンのプロジェクトにアクセスすると、対応するバージョンのライブラリも取得されます。タグを作る必要さえありません:-)
プロジェクト Aがhg push
祝福されたリポジトリに変更を加えると、Mercurial はサブリポジトリの変更を最初に独自のオリジンに確実にプッシュします。こうすることで、未公開のライブラリの変更に依存するプロジェクトの変更を誤って公開することがなくなります。
すべてをローカルに保持したい場合でも、サブリポジトリ定義で URL の代わりに相対パスを使用することで、このワークフローを使用できます。