私は数年前から hg ユーザーであり、それについて満足しています!
今までやったことのないプロジェクトを始めなければなりません。アイデアは、バッチ モードと GUI を備えたソフトウェアを開発することです。
そのため、バッチ モードと GUI モードの両方に共通のソースがありますが、それぞれに特定のソースも含まれます。そして、基本的には、同僚が GUI バージョンのクローンを作成し、変更をコミットできるようにしたいと考えています。次に、共通ファイルの変更をバッチ バージョンとマージできるようにしたいと考えています。
どうすれば対処できますか？
このトピックについて少し読んでいるので、助けていただければ幸いです!!
ありがとうございました。ビヌア
サブレポの作成者として、これにはサブレポを使用しないことを強くお勧めします。
サブリポジトリは、大きなプロジェクトを小さな断片に分割するために使用できますが、この利点は、サブリポジトリに伴う追加の複雑さと脆弱性によってしばしば補われます。プロジェクトが非常に大規模になる場合を除き、単純にするために 1 つのプロジェクト リポジトリに固執する必要があります。
では、サブレポは何のためにあるのでしょうか。サブリポジトリは、独立したプロジェクトのコレクションを管理するのに最適です。たとえば、既存の SCM をラップする大規模な GUI ツールを構築しているとします。次のような構造にすることをお勧めします。
scm-gui-build/ <- master build repo with subrepos:
scm-gui/ <- independent repo for all the code in your GUI tool
scm/ <- repo for the third-party SCM itself
gui-toolkit/ <- a third-party GUI toolkit you depend on
extensions/ <- some third-party extension to bundle
extension-foo/
ここではすべての作業を単純な古いリポジトリ (scm-gui) で行いますが、より高いレベルでマスター リポジトリを使用して、コレクション全体の構築/パッケージ化/バージョン管理/タグ付け/リリースを管理します。マスターscm-gui-buildリポジトリは、他の通常のリポジトリのシン ラッパーにすぎません。つまり、何かが壊れた場合 (リポジトリの URL の 1 つがオフラインになるなど)、プロジェクトで問題なく作業を続けることができます。
(参照: https://www.mercurial-scm.org/wiki/Subrepository#Recommendations )