Mercurial subrepositories - управление более сложными иерархиями зависимостей
У меня есть мастер-проект, в котором используется довольно стандартный подход с исходным деревом + ртутные подкаталоги.
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 of =) - но это не поможет моему сценарию, насколько я понимаю. Я не думаю, что есть какой-то способ заставить LHS жить вне хранилища Master, что, как мне кажется, мне действительно нужно здесь.
У меня есть пара идей, как это исправить, но ни одна из них не подходит мне, и я предполагаю, что должен быть лучший путь. Мое идеальное решение позволяет мне совместно использовать один и тот же суб-репо среди нескольких проектов без уплаты штрафа за наличие нескольких копий. Это просто кажется расточительным и неэффективным в моем сценарии здесь (плюс, я хотел бы, чтобы все проекты, которые зависят от Sub1, использовали ту же ревизию hg, а не пересматривались независимо)
Удалите Sub1 как подпункты Master и измените любые относительные пути в Master-решении, чтобы ссылаться на дважды вложенный Sub1. Эта структура пути не только отвратительна, но если добавить Sub3 к мастеру, который зависит от Sub1, у меня все еще есть 2 копии Sub1.
Скомпилируйте копию Sub1 и просто поместите ее в каталог \ lib. Sub1 все еще подвергается некоторому оттоку, и я бы предпочел построить против исходных версий. Я не хочу платить налог за постоянное копирование в новых двоичных файлах в исходное дерево все время (и раздувание дерева).
Каким-то образом нарушить зависимость Sub2 от Sub1. Исходя из архитектуры репозиториев, этого, вероятно, не произойдет. Sub1 содержит код общей библиотеки общего назначения. Sub2 содержит контракт / интерфейс / типы сервисов WCF, которые необходимы в двух очень отдельных проектах - клиентском SDK и серверной реализации. На данный момент имеет смысл хранить эти репозитории отдельно.
Может быть, я думаю об этом неправильно... или, может быть, я не знаю какой-то трюк HG.
Любая помощь приветствуется.
2 ответа
Я бы сказал, забудьте о проверке в двоичных файлах, это просто приводит к вздутию хранилища. IMO, любой вывод из сборки не должен храниться в исходном репозитории.
Как насчет обучения Sub2 ожидать, чтобы найти Sub1 в../Sub1? Затем, если вы обнаружите, что вам нужно работать на Sub2 независимо от Sub1, создайте репо "Sub2_standalone", в котором Sub1 и Sub2 будут задействованы как суб-репо.
Итак, работая над всем, вы получите:
Master/
Master/source/contrib/Sub1
Master/source/contrib/Sub2
Но когда просто работаю над Sub2:
Sub2_standalone/
Sub2_standalone/Sub2
Sub2_standalone/Sub1
Если вам нужна эта вложенная структура, вы можете использовать символическую ссылку для Sub1 ниже Sub2, чтобы обе версии Sub1 всегда были в одной и той же ревизии. Тогда у вас на самом деле есть только одна версия Sub1, которая, кажется, вам нужна.
В GNU/Linux это будет просто ln -s source/contrib/Sub1 source/contrib/Sub2/source/contrib/Sub1