Стратегия использования контроля версий в модульной системе

Давайте предположим (для простоты), что у нас есть приложение с клиентом и сервером; Есть ли лучшая идея использовать один репозиторий для обоих или пару отдельных репозиториев?

Их смешивание, вероятно, облегчит отслеживание коррелированных изменений и поддержание коррелированных ветвей (то есть эволюцию протокола), но, с другой стороны, сделает отдельные разработки более загроможденными ...

Если вы используете Git или Mercurial , то вы можете посмотреть на субмодули или суб-репозитории .

Клиент, сервер и их файлы интерфейса будут находиться в своих собственных репозиториях, но будут связаны друг с другом на уровне супер-репозитория . Это позволит вам выполнить одну проверку на верхнем уровне и / gitили hgпроверить соответствующую фиксацию каждого из подмодулей / под-репозиториев.

Зафиксировав супер-репозиторий только в том случае, если и клиент, и сервер соответствуют друг другу, супер-репозиторий только когда-либо даст вам возможность проверить работающую систему - так что вы никогда не будете пытаться запустить нового клиента против старого сервер или наоборот.

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

_{Этот ответ не предназначен для защиты gitили hgнад другими СКМ, просто так получилось, что я знаю эти СКМ достаточно хорошо, чтобы знать, что этот вариант существует. svnНапример, я не понимаю, как работают внешние устройства.}

Раздельное!

Фактически, у меня, вероятно, было бы три репозитория, один для клиента и соответствующих клиентских библиотек, один для сервера (и соответствующих библиотек) и один для общих библиотек (включая интерфейсы API, которые предоставляют функциональность между двумя , плюс любой другой общий код). Я думаю, что это действительно ключ, общий код должен идти в отдельный собственный репозиторий. Таким образом, вы можете быть уверены, что совместимость между вашим клиентом и сервером всегда одинакова, и она изолирована от дизайна каждого из его потребителей.

Очевидно, что это не всегда возможно, в зависимости от конкретной используемой коммуникационной среды, но, скорее всего, будет общий код, который определяет формат объектов передачи данных или шаги рукопожатия в вашем пользовательском протоколе (или некотором другом примере) ,

Предполагая, что у вас достаточно приличная настройка Continuous Integration и QA (довольно большое предположение, по моему опыту, но я все же сделаю это. Если у вас нет отдела QA, вы должны хотя бы получить некоторую CI), вы не должны Вам не нужно использовать шаблон с одним репо в качестве защиты от возможных несовпадений кода, либо ваш CI-сервер отметит совместимость библиотек, либо ваша команда QA обнаружит ошибки времени выполнения (или, что еще лучше, ваши юнит-тесты).

Преимущества разделенных репозиториев заключаются в возможности раздельного создания версий отдельных частей системы. Хотите взять копию Сервера прошлой недели и запустить его вместе с Клиентом этой недели, чтобы попытаться устранить причину проблемы с производительностью? Не стоит беспокоиться.

В Mercurial эту схему можно использовать, ->чтобы обозначить взаимосвязь субрепаратов:

product -> client -|-> (many components)
                   |->  shared component A

        -> server -|-> (many components)
                   |->  shared component A

Продукт имеет подпункты клиент, сервер. Каждый из них имеет свои компоненты в качестве вложенных элементов, возможно, по крайней мере, один вложенный отчет разделен между ними.

Пометка, вероятно, должна быть сделана на первых двух уровнях, не ниже этого.

Коммиты выполняются на уровне компонентов, суперотношения эффективно отслеживают именованные ветви и версии продукта. Именованные ветви / закладки, как правило, лучше, чем ветви-клоны, по удобству использования (т.е. обучаемости) и совместимости с подпунктами.

hg склоняется к предположению, что superrepos - это продукт, а фиксация выполняется на верхнем уровне, но это не очень хорошо работает, когда несколько продуктов используют одни и те же компоненты. :-)

Я не думаю, что эта схема сильно изменится, если перейти на git, но я еще не пробовал ее в git.

Это проблема управления конфигурацией, а не проблема контроля версий. Как всегда, программист с помощью отвертки забивает гвоздь. Подумайте, как вы будете управлять своими конфигурациями, контроль ревизий позаботится о себе сам.

Самый простой подход состоит в том, чтобы использовать один репозиторий, поэтому, если вы не любите сложность ради сложности, тогда это должно быть выбором по умолчанию в отсутствие убедительных аргументов в противном случае.

Планируется ли разработка клиента и сервера различными организациями? Будет ли несколько реализаций клиента (или сервера)? Является ли клиент открытым исходным кодом и реализация сервера секретной? Если ответом на все эти вопросы является «Нет», то что-либо более сложное, чем один репозиторий, может принести только неудобства без пользы.

Если вы решите поддерживать отдельные кодовые базы, вам потребуются четкие политики относительно того, как это администрируется, чтобы избежать несовместимости и адской зависимости. Проработав первые несколько икок, вы можете обнаружить, что самое безопасное - всегда проверять оба хранилища вместе, собирать их вместе и развертывать их вместе ... что, очевидно, сводит на нет всю цель их разделения!

Модульность - это хорошее свойство, но разделение репозиториев не является инструментом для достижения этой цели. Как следует из предыдущего абзаца, вы можете иметь сильно связанные компоненты, которые разбиты на несколько кодовых баз (нежелательно), и аналогично вы можете иметь высокомодульные компоненты в одной и той же кодовой базе (желательно).

Я неоднократно выступал (успешно) за то, чтобы моя команда объединила существующие git-репозитории, потому что это упростило разработку и развертывание.

Забудьте о хранилище на мгновение. Как бы вы организовали два проекта на вашем компьютере, если бы вы ни с кем не делились? Как бы остальная команда сделала это? Не могли бы вы...

• Поместить все исходные файлы для клиента и сервера в один каталог?

• Создать основной каталог проекта, который содержит подкаталоги для клиента и сервера?

• Держите два проекта совершенно отдельно?

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

Например, в Subversion наибольшее различие между отдельными хранилищами для клиента и сервера и единым объединенным хранилищем заключается в том, как меняются номера редакций. В одном репозитории номер версии будет увеличиваться каждый раз, когда вы передаете код клиенту или серверу. В отдельных репозиториях фиксация в проекте сервера не изменит номер ревизии заголовка для клиента.