Управление фирменным программным обеспечением в системе контроля версий

Question

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

Что может быть хорошим способом сохранить эти различия, но при этом иметь возможность легко извлекать все, что вам понадобится для сборки релиза для сборки ствола или сборки с файлом пользовательского ресурса?

Answer 1

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

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

Answer 2

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

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

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

Answer 3

Ну, вы можете либо использовать наборы слияний, где вы просто объединяете диапазон коммитов, или вы можете хранить файлы фирменных ресурсов в отдельном каталоге в корне ветви (ов)? Затем при слиянии просто выберите каталоги в корне, исключая брендинг.

Мне нравится объединять только ряд коммитов, так как это позволяет избежать новой работы над ветками. Но если вам нужно объединить все, вы можете переместить свой проект в подкаталог (например, «Source»), а брендинг - во второй подкаталог. Затем в Eclipse или в любом другом месте, которое вы можете просто выбрать для объединения из магистрали / источника в ветку / источник.

например:.

это:
/ СВН / проектируемый / багажник / а
/ СВН / проектируемый / багажник / б
/ СВН / проектируемый / багажник / с
/ СВН / проектируемый / багажник / d / E / F / Брендинг

становится таким:
/ СВН / проектируемый / багажник / источник / а
/ СВН / проектируемый / багажник / источник / б
/ СВН / проектируемый / багажник / источник / с

/ SVN / проектируемый / филиал / Брендинг
/ СВН / проектируемый / филиал / источник / а
/ СВН / проектируемый / филиал / источник / б
/ СВН / проектируемый / филиал / источник / с

Answer 4

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