Несколько репозиториев или один репозиторий с ветками?

Question

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

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

Какую настройку вы / будете использовать в этой ситуации?

Answer 1

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

Я не понимаю, почему иметь проблемы с пересмотром номеров пропущенных веток было бы проблемой.

Для справки: На работе все проекты всего отдела разработки программного обеспечения (60 программистов) находятся в одном хранилище SVN.

Answer 2

Один репозиторий. Ветви и метки по пути. Это действительно не проблема, когда вы привыкнете к этому.

Имеют несколько хороших практик управления выпусками и помогут в этом (например, отследят, какая версия / ветка имеет какую функцию и т.

Answer 3

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

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

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

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

Answer 4

Я бы пошел с одним хранилищем с несколькими ветвями. Я не думаю, что вам нужно беспокоиться о номерах ревизий - дайте своим ветвям хорошие имена и используйте теги, чтобы ссылаться на различные варианты внешнего использования (например, создайте тег для сборки 3 ветви A). Таким образом, вам нужно беспокоиться только о номерах ревизий при работе с SVN.

Answer 5

В дополнение ко всем тем, которые рекомендуют ветки, а не несколько репозиториев, увеличение количества ревизий для незатронутых ветвей на самом деле не является недостатком.

Answer 6

Лично я бы предложил использовать DVCS (чтобы не препятствовать использованию Subversion) и иметь отдельный репозиторий для каждого проекта.

Если есть общая история, то эти репозитории могут быть связаны. Если вы никогда не использовали DVCS до , я бы посоветовал Mercurial , потому что его довольно легко изучить и одинаково хорошо работает в Windows и Linux.

Answer 7

Один из способов - создать репозиторий для общей, базовой функциональности и репозиторий для каждого проекта, который зависит от ядра, где будут сделаны настройки. Ваши дочерние проекты могут извлекать основные файлы, используя определение svn: externals .

Это предполагает, что основные функции достаточно модульны, чтобы поддерживать эту изоляцию.

Answer 8

Я использую GIT, потому что он лучше обрабатывает ветвления и слияния :) Но для SVN это будет зависеть от того, сколько проектов и как они связаны. Если код является частью одной и той же программы, я бы делал разные ветки.

Если они являются изолированными проектами, вам следует использовать разные репозитории.

Answer 9

Если все они являются разными штаммами одной и той же кодовой базы, я бы поместил их в ветки (в одном репозитории)

Я обычно использую новый репозиторий только для различных программ.