У нас есть большой проект ПО, который в настоящее время находится в репозитории SVN, и мы должны поддерживать несколько веток выпуска одновременно.
В настоящее время у нас есть один репозиторий для кода и отдельный репозиторий для графических ресурсов и переводов. Конечный продукт сильно зависит от ресурсов и переводов (правил).
Большую часть времени мы разветвляем код, создавая «ветки долгосрочной поддержки / обслуживания», где код стабилизируется и тестируется, в то время как разработка продолжается на ветки основных версий (разработка на основе ствола). Это приводит к большому слиянию LTSB с разработчиками и наоборот.
Это только для части кода, потому что мы также должны поддерживать ветку Assets, все изменения в зависимости от изменений кода должны применяться и к этой ветке (-ам).
Пример ветвей
Все ветки «дублируются» в отдельных репозиториях из-за разделения кода и активов.
trunk
--trunkLTSB1
--trunkLTSB2
MajorRelease1.0.0.0
--MajorRelease1LTSB1.1.0.0
--MajorRelease1LTSB1.2.0.0
MajorRelease2.0.0.0
--MajorRelease2LTSB2.1.0.0
--MajorRelease2LTSB2.2.0.0
Иногда нам приходится исправлять ошибки в нескольких ветках LTSB и MajorRealease, что приводит к слиянию одного исправления 5,6 или 7 раз (полный ад слияния).
Теперь у нас есть файл XML, определяющий HowTo / Справочные экраны в нашем SW. Каждый узел в файле зависит от настроек и конфигурации ПО, эти экраны HowTo / Help отображаются для конечного пользователя. Для этого XML также существуют зависимые файлы переводов. И для некоторых узлов в XML мы зависим от функций в коде для их рендеринга.
Пример
Если функция X включена, мы показываем HowTo для эта функция в разделе справки. Мы могли бы вызвать функцию FooBar () для рендеринга составного графика c, который использует изображения из ветки ресурсов.
Функциональные возможности / поведение функций могут различаться в разных ветвях, а также настройки могут отличаться в разных ветвях. Изображения могут меняться между ветвями.
Вопрос
Из-за всех проблем, с которыми мы уже столкнулись при объединении и поддержке нескольких ветвей, мы не уверены, как изменить эту версию XML файл и зависимые переводы. На данный момент XML и переводы будут находиться в репозитории Assets, и только один человек будет активно работать над ним (коммит).
Мы оцениваем два возможных варианта того, как версия XML файл:
1. Информация о версии c Каждый узел XML будет определять конкретные c версии (ветки / выпуски), с которыми он совместим, поэтому мы получаем один XML файл (переводы) в одной ветке и в нескольких ветках. зависимые узлы для «одинаковой» функциональности
2. Ветвление Каждая ветвь актива имеет свой собственный XML файл и переводы, и человек, работающий над ним, при необходимости заботится о слиянии с LTSB и MajorBranches.
Большая часть разработки выполняется на последних основных релиз ветки, иногда по другим. Стоит ли внедрять и поддерживать внутреннее управление версиями в XML или просто придерживаться слияния, учитывая, что человек, поддерживающий XML, не является разработчиком? Какой вариант лучше - или есть другой вариант лучше?
PS Мы переносим репозитории на GIT в самое ближайшее время.