Отслеживание собственных библиотек в субпозиториях

Мы разрабатываем собственный фреймворк, который будут использовать несколько проектов. Идея состоит в том, чтобы отслеживать всю структуру как непрерывный подрепозиторий репозитория каждого проекта. В результате получилось следующее дерево вложенных репозиториев (см. тонкий репозиторий):

ProjectMaster/
    Project/
    CommonLib/
    FrameworkMaster/
        Framework/
        CommonLib/
  • Имеет ли это для вас смысл? Есть ли лучший / более простой способ справиться с этими зависимостями, не связанный с подкреплениями?
  • В частности, имеет ли смысл иметь оба подрепозитория CommonLib?
  • Если нет, имеет ли смысл для Project использовать FrameworkMaster / CommonLib? Это могло бы стать беспорядочным, если бы зависимости были более сложными.
  • Where would you open feature branches? On the master? Only in the relevant subrepository?
    • If you don't have feature branches on the master, every time you clone the repository you end up getting the subrepo state of the last commit, which may put any subrepo in any random feature branch. Very confusing.
    • Если у вас есть функциональные ветки на главном сервере, вам все равно нужна функциональная ветка хотя бы в одном подрепо, чтобы избежать там безымянных головок.

В общем, с этим решением сложно работать. Какие-либо предложения?


version-control dependency-management mercurial subrepos mercurial-subrepos
person Itay Perl    schedule 01.11.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Согласно описанию в документации тонкого репозитория:

For a thin-shell repository, all repositories containing 'real' code 
have no subrepositories of their own (ie. they are leaf nodes). They can 
thus be treated as completely ordinary repositories and a developer can 
largely ignore the additional complexities of subrepositories. Work can 
continue in these repositories even if their siblings become unavailable.

Результирующая структура, которую вы описали, имеет вложенные подхранилища, которые содержат «настоящий» код и, следовательно, это не рекомендуемый способ. Согласно документации Mercurial, рекомендуемая структура будет следующей (я не знаю, был ли / FrameworkMaster / включен как просто заполнитель для вложенных субпозиториев или он также имеет «настоящий» код. Если / FrameworkMaster / также имеет «настоящий» код тогда он также должен быть включен в следующий как родственный листовой узел):

ProjectMaster/
    Project/
    Framework/
    CommonLib/

Итак, чтобы ответить на ваши вопросы:

  • Имеет ли это для вас смысл? Есть ли лучший / более простой способ справиться с этими зависимостями, не связанный с подкреплениями?

Лучшим / более простым способом было бы использовать репозиторий тонкой оболочки для упрощения сложных зависимостей.

  • В частности, имеет ли смысл иметь оба подрепозитория CommonLib?

Если и Project, и Framework зависят от одной и той же версии или ветки CommonLib, то нет смысла иметь ее в обоих местах. Но если по некоторым устаревшим причинам Project и Framework требуют другую версию или ветвь CommonLib, тогда имеет смысл иметь CommonLib в обоих местах.

  • Где бы вы открывали ветки функций? На мастере? Только в соответствующем подрепозитории?

Не уверен, что вы подразумеваете под функциональными ветвями. Вы хотели сказать здесь «будущее»?

person samirjaiswal    schedule 10.12.2012
comment
Интересный. Я полагаю, что FrameworkMaster могут использовать только разработчики фреймворка. Под ветвями функций я ссылался на именованные ветки, используемые для разработки конкретной функции (см. здесь) . - person Itay Perl; 10.12.2012
comment
В этом случае имеет смысл иметь отдельный репозиторий тонкой оболочки для FrameworkMaster, который включает только суб-репозитории Framework и CommonLib. Таким образом, разработчики проектов и разработчики фреймворков работают над одной и той же кодовой базой. - person samirjaiswal; 11.12.2012