Решение для контроля версий для системы сборки, которая выдает ISO 4 ГБ

Question

У меня есть программный проект, который на последнем этапе его сборки, после создания всех jar-файлов и связанных скриптов / конфигурационных файлов, мне нужно установить его в CentOS ISO, который имеет конфигурационный файл kickstart, на котором выполняются некоторые сценарии после установки и устанавливает некоторые настроенные RPM.

Проект находится в репозитории SVN и строится оттуда. Я не могу вставить файлы ISO в репозиторий, потому что SVN не обрабатывает 4 ГБ репозитория. С другой стороны, проблема в том, что некоторые из RPM в ISO могут меняться от версии к версии, и когда я хочу построить более старую версию проекта, я в плохом месте, потому что RPM не в SVN хранилище.

Есть ли хорошее решение для управления версиями, которое я могу использовать только для 4 ГБ ISO, которые могут обрабатывать такой объем данных? Есть ли решение для контроля версий, которое я пытаюсь сделать?

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

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

Спасибо!

Answer 1

Если вам действительно нужно хранить большие артефакты (ISO, RPM, ...), для которых:

• вам не нужно сравнивать различия между версиями
• вам не нужно делать параллельные эволюции (артефакты только для чтения)

тогда вам на самом деле не нужна VCS (система контроля версий).

Вам нужен репозиторий артефактов, например Nexus .
См. « Рекомендации по хранению файлов .jar в VCS (SVN, Git,…) »

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

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

Answer 2

Если вам нужны воспроизводимые выходные данные сборки, то вам нужно создать версию полного набора входных данных сборки.Это включает в себя RPM или, по крайней мере, манифест их версий, если они могут быть надежно получены откуда-то.Сохранение сгенерированного ISO будет бесполезным упражнением.

Answer 3

А как насчет мерзавца? (http://git -scm.com )

Answer 4

Почему вы должны хранить ISO или RPM в управлении версиями?

Почему бы не сохранить сценарии и / или конфигурации, которые могут перестроить ISO и RPM, которые вам нужны?

Answer 5

Я думаю, вы можете проверить GIT (http://git -scm.com / ) - бесплатно или Perforce (http://www.perforce.com) (стоит). Я думаю, что оба могут обрабатывать файлы 4 ГБв своих хранилищах.