У меня есть мастер-проект, в котором используется довольно стандартный подход с исходным деревом + ртутные субпозитории.
Master
\lib - compiled binaries - things like log4net, AutoFac, etc
\source - VS solution, one folder per project, etc
\tools - stuff used during the build process
\source\contrib - contains any subrepos like so:
\source\contrib\Sub1
\source\contrib\Sub2
Master\.hgsub contains something like
source\contrib\Sub1 = https://myserver.com/Sub1
Недавно было определено, что для Sub2 требуется некоторый код из Sub1, и, следовательно, я должен настроить его наэта новая структура зависимостей.
Проблема, конечно, заключается в том, что, если я буду следовать тому же подходу, который описан выше, и добавлю Sub1 в качестве подпунктов Sub2, я получу эту ужасную ситуацию.
\source\contrib\Sub2\source\contrib\Sub1
У мастера теперь есть 2 независимые копии Sub1!
Так что я знаю, что я должен использовать относительные пути при ссылках на подпункты (RHS =) - но это не поможет моему сценарию здесь, так как японимать это.Я не думаю, что есть какой-то способ заставить LHS жить за пределами Мастер-хранилища, что, как мне кажется, мне действительно нужно здесь.
У меня естьпара идей о том, как это исправить, но ни одна не подходит мне, и я предполагаю, что должен быть лучший путь.Мое идеальное решение позволяет мне совместно использовать один и тот же суб-репо среди нескольких проектов без уплаты штрафа за наличие нескольких копий.Это просто кажется расточительным и неэффективным в моем сценарии (плюс, я хотел бы, чтобы все проекты, которые зависят от Sub1, использовали одну и ту же ревизию hg, а не пересматривались независимо)
Удалите Sub1 как вложенные элементы Master и измените любые относительные пути в Master-решении, чтобы ссылаться на дважды вложенный Sub1.Эта структура пути не только отвратительна, но если добавить Sub3 к мастеру, который зависит от Sub1, у меня все еще есть 2 копии Sub1.
Скомпилируйте копию Sub1 и просто бросьтеэто в каталоге \ lib.Sub1 все еще подвергается некоторому оттоку, и я бы предпочел построить против исходных версий.Я не хочу платить налог за постоянное копирование в новые двоичные файлы в исходное дерево все время (и раздувание дерева).
Каким-то образом нарушить зависимость Sub2 от Sub1.Исходя из архитектуры хранилищ, этого, вероятно, не произойдет.Sub1 содержит код общей библиотеки общего назначения.Sub2 содержит контракт / интерфейс / типы сервисов WCF, которые необходимы в двух очень отдельных проектах - клиентском SDK и серверной реализации.На данный момент имеет смысл держать эти репозитории раздельными.
Возможно, я думаю об этом неправильно ... или, может быть, я не подозреваю о каком-то трюке с hg.
Любая помощь приветствуется.