SVN: структура репозитория, когда две разные версии разрабатываются параллельно?

Question

Я совершенно новичок в Subversion, и я хочу знать, как структурировать хранилище. Как я читал, каталог «ствол» предназначен для основной разработки, «теги» - это снимок версии, «ветки» - для внесения значительных изменений / тестирования, а не для нарушения работы транка.

Проблема в том, что когда у вас есть две основные версии для параллельной разработки: я не очень хорошо понимаю, как это структурировать. Я беру пример языка Python, обе версии 2 и 3 находятся в стадии разработки, я вижу следующие возможности структуры:

1st one :
===========

repos/
  python2/
    trunk/
    tags/
      V2.5/
      V2.6/
      V2.7/
    branches/
      big_modif1/
      testing2/
  python3/
    trunk/
    tags/
      V3.0/
      V3.1/
      V3.2/
    branches/
      big_modif43/
      testing37/

2nd one :
===========

repos/
  python/
    trunk/
      V2/
      V3/
    tags/
      V2.5/
      V2.6/
      V2.7/
      V3.0/
      V3.1/
      V3.2/
    branches/
      big_modif_on_v2.x/
      testing2_on_v2.x/
      big_modif43_on_v3.x/
      testing37_on_v3.x/

3rd one :
===========

repos/
  python/
    trunk/
    tags/
      V2.5/
      V2.6/
      V2.7/
      V3.0/
      V3.1/
      V3.2/
    branches/
      V2_trunk/
      V3_trunk/
      big_modif_on_v2.x/
      testing2_on_v2.x/
      big_modif43_on_v3.x/
      testing37_on_v3.x/

Что вы выберете (конечно, вы можете предложить что-то еще)?

Answer 1

Я думаю, что комбинация может быть лучшей.Позвольте мне объяснить это на вашем примере:

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

Поэтому я бы следовал «макету репозитория одного проекта» (описанному в SVN red book ):

repos/
  python/
    trunk/
    branches/
      V2/
    tags/
      ...
      V2.7/
      ...
      V3.2/

Суть в том, что V2 был разветвлен, когда началась разработка версии 3.И что вам следует придерживаться следующих правил слияния:

• Объединять только исправления ошибок в V2 с транком, если они совместимы с ним.
• Не объединять с транка (== V3) до V2.

Answer 2

Мы используем немного другую структуру хранилища для SVN:

Магистраль - это то, что в данный момент живо.

Создание веток разработки для всех разработок. Как правило, во всех проектах у нас есть основная ветвь разработки (или Альфа), которую используют основные проекты, затем мы создаем дополнительные ветки по мере необходимости.

Создавайте теги во время развертываний для тестирования, использования, трансляции и т. Д., А затем объединяйтесь с транком после успешного развертывания в производственной среде.

Если вы работаете параллельно (например, исправление ошибок), после объединения обратно с транком объедините изменения с оставшимися активными ветвями.

Секрет, как и в случае любого контроля над источниками, заключается в том, чтобы команда следовала принятым вами правилам.

Answer 3

Любой макет только Принято соглашение

• Ничто не запрещает создавать два подкаталога на основе структуры репо по умолчанию, т. Е. Ваш v2 (с, вероятно, разделенными ветвями с одинаковым образом), v1 также может использоваться
• Вы можете подумать о разделении разработки на разные репозитории (связанные с внешними, когда и где это необходимо)