Контроль версий для нескольких проектов, расширяющих один проект - PullRequest
1 голос
/ 04 февраля 2010

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

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

Мне повезло, что мне позволили полностью покончить с SVN и перейти к чему-то другому, если это более уместно.

У нас есть

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

Наш процесс

  • Изменения в основном дереве исходных текстов вручную включаются в специфичные для домена деревья
  • Иногда изменения в деревьях, специфичных для домена, считаются «общими» / достаточно хорошими для включения обратно в основное дерево (и, в конечном итоге, во все другие деревья, специфичные для домена)

То, что мы хотели бы, это технология (или технологии), которые могут

  • Разрешить каждому дереву, специфичному для домена, строить против определенной ревизии в базовом дереве (т. Е. Процесс компоновки захватывает конкретную ревизию ядра, а затем применяет все изменения, относящиеся к домену, поверх него для создания конечного продукта)
  • Позволяет каждому дереву, специфичному для домена, изменять конкретную версию ядра для сборки (Это может привести к ошибкам сборки, но пока процесс изменения относительно прост и прост в использовании).
  • Укажите метод для дерева, специфичного для домена, для внесения изменений в основной репозиторий.
  • Поскольку базовое базовое дерево является открытым исходным кодом, а доменные деревья НЕ являются таковыми, нам потребуется некоторая форма контроля доступа в некоторых частях окончательного решения.

Заранее спасибо за любую помощь.

1 Ответ

1 голос
/ 04 февраля 2010

Я бы рассматривал их как отдельные проекты в вашей системе контроля версий.

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

Или вы можете использовать svn: externals, чтобы SVN автоматически проверял версию вашего основного проекта всякий раз, когда вы проверяете проект для конкретного домена.

...