Вложенная схема контроля версий?

Question

Поиск предложений о том, как наилучшим образом отслеживать структуру этого проекта в каком-либо контроле версий (предпочтительно git или svn):

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

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

С точки зрения структуры это будет выглядеть примерно так:

/-+
  |
  +--index.php
  +--engine/
  |  |
  |  +--1.0-stable/
  |  |  |
  |  |  +--feature.php
  |  +--2.0-beta/
  |     |
  |     +--feature.php
  +--main.css
  +--main.js

Итак, index.php, main.css и main.js являются частью их собственного "проекта", который является веб-интерфейсом, в то время как 2.0-beta является отдельной веткой разработки, обновления которой в конечном итоге будут объединены в 2.0-stable ветвь, и любые исправления к feature.php в ветке 1.0 в должны также быть объединены с файлом 2.0 feature.php.

Могу ли я создавать репо внутри репо? Как лучше всего с этим справиться?

Answer 1

Если ваша структура каталогов не должна выглядеть таким образом, у меня будет два репозитория: один для движка и один для инфраструктуры. У репозитория движка есть две (или более) ветви, и каждая из этих ветвей имеет репозиторий инфраструктуры в виде подмодуля (для git; или svn: externals, если вы использовали SVN).

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

Answer 2

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

/-+
  |
  +--discovery/
  |  |
  |  +--index.php
  |  +--main.css
  |  +--main.js
  +--engine/
     |
     +--1.0-stable/
     |  |
     |  +--feature.php
     +--2.0-beta/
        |
        +--feature.php

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

В этом случае развертывание из системы контроля версий будет достаточно стандартным для каталога каждой версии механизма.

Answer 3

Вам не нужно создавать репо внутри репо.Фактически, если вы используете Subversion, например (в git это похоже), когда вы хотите создать ветку, вы можете сделать это путем копирования (svn cp).Subversion выполняет копирование при записи (или копирование при модификации), поэтому вы можете работать в отдельных каталогах, которые будут храниться отдельно.Затем вы можете объединить изменения в каждой ветви (subdir).

Answer 4

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

Общий код может храниться в ветви по умолчанию (master или trunk, в зависимости от вашего выбора scm).

Вам следует использовать автоматическое развертывание из scm, затем вы можете настроить его так, чтобы оно развертывало только выбранные ветви.

Answer 5

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