#mercurial #mercurial-subrepos
#mercurial #mercurial-вложенные репозитории
Вопрос:
Я являюсь пользователем hg уже пару лет, и я рад этому!
Я должен начать проект, как никогда раньше. Идея состоит в том, чтобы разработать программное обеспечение с пакетным режимом и графическим интерфейсом.
Таким образом, будут общие источники как для пакетного, так и для графического интерфейса, но каждый из них также будет содержать определенные источники. И, в принципе, я хотел бы, чтобы мои коллеги могли клонировать версию GUI, работать над ней и вносить изменения. Затем я хотел бы иметь возможность объединить их изменения в общих файлах с пакетной версией.
Как я могу с этим справиться?
Поскольку я немного читал по этой теме, я был бы очень признателен за любую помощь!!
Спасибо. binoua
Комментарии:
1. Если вы категорически против смешивания всех источников в одном проекте и управления различиями с помощью нескольких файлов проекта (я не знаю, какую проектную систему вы используете), рассматривали ли вы вложенные репозитории? Поместите все общие файлы в дочернее хранилище и создайте 2 новых репозитория, оба из которых включают общий?
2. @Lasse: судя по тегам, я полагаю, что у него есть, и он просто хочет знать, будет ли / как это работать.
Ответ №1:
Как создатель вложенных репозиториев, я настоятельно рекомендую не использовать вложенные репозитории для этого.
Хотя вложенные хранилища можно использовать для разбиения более крупного проекта на более мелкие части, преимущества этого часто перевешиваются дополнительной сложностью и хрупкостью, которые связаны с вложенными хранилищами. Если ваш проект не будет действительно большим, вы должны просто придерживаться одного репозитория проекта для простоты.
Так для чего же тогда нужны вложенные репозитории? Вложенные репозитории лучше всего подходят для управления коллекциями независимых проектов. Например, предположим, что вы создаете большой инструмент с графическим интерфейсом, который оборачивается вокруг существующего SCM. Я бы порекомендовал вам структурировать его примерно так:
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-адресов репозитория отключится), вы можете продолжать работать в своем проекте без проблем.
(см. Также: https://www.mercurial-scm.org/wiki/Subrepository#Recommendations )
Комментарии:
1. Спасибо за ваш ответ. Итак, если я вас понимаю, нет правильного способа клонировать только репозиторий GUI или только пакетный репозиторий?
2. Это совсем не то, что я сказал. Прочитайте второй абзац еще раз. Вы можете разбить свой проект на вложенные репозитории, но это не значит, что вы должны это делать.