Как использовать подрепозитории mercurial для общих компонентов и зависимостей?

Мы разрабатываем программное обеспечение.NET Enterprise на языке C #. Мы стремимся улучшить нашу систему контроля версий. Раньше я использовал mercurial и экспериментировал с ним в нашей компании. Однако, поскольку мы разрабатываем корпоративные продукты, мы уделяем большое внимание повторно используемым компонентам или модулям. Я пытался использовать субрепозитории mercurial -для управления компонентами и зависимостями, но у меня возникли некоторые трудности. Вот основные требования к системе контроля версий/управлению зависимостями:

1. Многоразовые компоненты
   1. Совместно с источником (для отладки)
   2. Наличие зависимостей от сторонних бинарных файлов и других повторно используемых компонентов
   3. Может быть разработан и передан в систему контроля версий в контексте потребляемого продукта
2. Зависимости
   1. Продукты зависят от сторонних двоичных файлов и других повторно используемых компонентов
   2. . Зависимости имеют свои собственные зависимости
   3. Разработчики должны быть уведомлены о конфликтах версий в зависимостях

. Вот структура в mercurial, которую я использовал:

Многоразовый компонент:

SHARED1_SLN-+-docs
            |
            +-libs----NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED1-+-proj1
            |                 +-proj2
            |
            +-tools---NANT

Второй многоразовый компонент, потребляющий первый:

SHARED2_SLN-+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED2-+-proj3
            |                 +-proj4
            |
            +-tools---NANT            

Продукт, который потребляет оба компонента:

PROD_SLN----+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-SHARED2-+-proj3
            |       |         +-proj4
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----prod----+-proj5
            |                 +-proj6
            |
            +-tools---NANT

Примечания

1. Репозитории написаны ЗАГЛАВНЫМИ БУКВАМИ
2. Предполагается, что все дочерние репозитории являются субрепозиториями
3. . Сторонние (бинарные )библиотеки и внутренние (исходные )компоненты — все вложенные репозитории, расположенные в папке libs
4. Сторонние библиотеки хранятся в отдельных репозиториях Mercurial, поэтому потребляющие проекты могут ссылаться на определенные версии библиотек (, т. е. старый проект может ссылаться на NLog v1.0, а новый проект может ссылаться на NLog v2.0 ).
5. Все файлы Visual Studio.csproj находятся на 4-м уровне папок (proj *), что позволяет использовать относительные ссылки на зависимости (, т. е.../../../libs/NLog/NLog.dll для всех Проекты Visual Studio, которые ссылаются на NLog)
6. Все файлы Visual Studio.sln находятся на 2-м уровне (в папках src ), поэтому они не включаются при «совместном использовании» компонента с потребляющим компонентом или продуктом
7. . Разработчики могут свободно организовывать свои исходные файлы по своему усмотрению, если они являются дочерними элементами папки proj *потребляющего проекта Visual Studio (, т. е. папок proj *может быть n дочерних элементов, содержащие различные источники/ресурсы)
8. Если Боб разрабатывает компонент SHARED2 и продукт PROD1, для него совершенно законно вносить изменения в источник SHARED2 (, например, источники, принадлежащие proj3 ), в репозиторий PROD1 _SLN, и фиксировать эти изменения. Мы не возражаем, если кто-то разрабатывает библиотеку в контексте потребляющего проекта.
9. Компоненты внутренней разработки (SHARED1 и SHARED2 )обычно включаются исходным кодом в потребляющий проект (в Visual Studio, добавляя ссылку на проект, а не просматривая ссылку на dll ). Это позволяет выполнять расширенную отладку (с переходом в код библиотеки ), позволяет Visual Studio управлять необходимостью перестроения проектов (при изменении зависимостей )и позволяет при необходимости модифицировать библиотеки (по мере необходимости. описано в примечании выше ).

Вопросы

1. Если Боб работает над PROD1, а Алиса работает над SHARED1, как Боб может узнать, когда Алиса вносит изменения в SHARED1. В настоящее время с Mercurial Боб вынужден вручную извлекать и обновлять каждое подрепозиторий. Если он отправляет/вытягивает на сервер из репозитория PROD _SLN, он никогда не узнает об обновлениях подрепозиториев. Это описано в Mercurial wiki .Как Боб может быть уведомлен об обновлениях вложенных репозиториев, когда он получает последнюю версию PROD _SLN с сервера? В идеале он должен быть уведомлен (предпочтительно во время извлечения ), а затем должен вручную решить, какие подрепозитории он хочет обновить.

2. Предположим, что SHARED1 ссылается на NLog v1.0 (commit/rev abc в mercurial ), а SHARED2 ссылается на Nlog v2.0 (commit/rev xyz в mercurial ). Если Боб усваивает эти два компонента в PROD1, он должен знать об этом несоответствии. Хотя технически Visual Studio/.NET позволяет двум сборкам ссылаться на разные версии зависимостей, моя структура не позволяет этого, поскольку путь к NLog фиксирован для всех проектов.NET, зависящих от NLog. Откуда Бобу знать, что у двух его зависимостей есть конфликты версий?

3. Если Боб настраивает структуру репозитория для PROD1 и хочет включить SHARED2, как он может узнать, какие зависимости требуются для SHARED2? С моей структурой ему пришлось бы вручную клонировать (или просмотреть на сервере )репозиторий SHARED2 _SLN и либо просмотреть папку libs, либо просмотреть файл.hgsub, чтобы определить, какие зависимости ему нужны. включать. В идеале это должно быть автоматизировано. Если я включаю SHARED2 в свой продукт, SHARED1 и NLog также автоматически -включаются магическим образом, уведомляя меня о конфликте версии с какой-либо другой зависимостью (, см. вопрос 2 выше ).

Большие вопросы

1. Является ли ртуть правильным решением?

2. Есть ли лучшая ртутная структура?

3. Является ли это допустимым использованием для вложенных репозиториев (, т.е. разработчики Mercurial пометили вложенные репозитории в качестве крайней возможности )?

4. Имеет ли смысл использовать mercurial для управления зависимостями? Мы могли бы использовать еще один инструмент для управления зависимостями (, может быть, внутренний канал NuGet? ). Хотя это будет хорошо работать для сторонних зависимостей,это действительно создало бы проблемы для компонентов, разрабатываемых внутри компании (, то есть, если бы они активно разрабатывались, разработчикам пришлось бы постоянно обновлять фид, нам пришлось бы обслуживать их внутри, и это не позволяло бы модифицировать компоненты проектом-потребителем. (Примечание 8 и вопрос 2 ).

5. У вас есть лучшее решение для программных проектов Enterprise.NET?

Ссылки

Я прочитал несколько вопросов SO и нашел этот полезным, но принятый ответ предлагает использовать специальный инструмент для зависимостей. Хотя мне нравятся функции такого инструмента, он не позволяет изменять и фиксировать зависимости из проекта-потребителя (, см. большой вопрос 4 ).