Я действительно новичок в Subversion и в концепциях управления версиями, и, хотя я могу справиться с регистрацией нескольких файлов в проекте, мне нужен совет, как масштабировать это для своих нужд.
По сути, мы разрабатываем среду, которая содержит множество сценариев и конфигураций, которые распределены по многим виртуальным и физическим машинам.Создайте сценарии, конфигурационные файлы, двоичные файлы, зеркала RPM и т. Д., И, хотя каждый из них в своем собственном мире в порядке, нам нужен способ объединить их в единую версию.Хотя в более крупном проекте по написанию кода я вижу, что это, вероятно, будет просто работать с папками в одном проекте SVN (насколько я понимаю, так что, вероятно, нет ...), эти теги действительно не имеют ничего общего, а многие даже не являются кодоми я просто представляю себе SVN в качестве заполнителя.Таким образом, нет смысла «проверять» собранную массу данных, но каким-то образом необходимо связать номер версии верхнего уровня с, возможно, 60 различными частями работы.Как и выше, это код, конфигурационные файлы, rpm и т. Д.
Я изначально предполагаю, что мы каким-то образом будем использовать SVN, но, возможно, это ошибочное предположение в первом случае.Тем не менее, с точки зрения общего назначения требований, я могу себе представить наличие реальных проектов в SVN, а затем проектов-оболочек, которые обновляются с помощью cronjob (или другого триггера) для ссылки на самые последние версии SVN каждого проекта, перечисленные в файле метаданных впроект обертки.Если какой-либо проект в списке изменился, то этот проект-обертка обновляется с добавлением нового файла метаданных.В свою очередь эти обертки обертываются другими обертками вплоть до одного главного проекта.Конечное использование этой мастер-версии проекта заключается в установлении базового уровня проектов под ним, которые можно будет использовать с системами документирования и отслеживания изменений, а также с уровнем автоматизации.
Хотя я могу предусмотретьто, что я только что описал, основано только на очень маленьком представлении о SVN и, вероятно, (надеюсь) упускает из виду многие аспекты существования SVN (или git .... ??).
Я надеюсьэто имеет смысл, извините, если это не так.Более чем рады попытаться уточнить что-либо.
Спасибо
Крис
РЕДАКТИРОВАТЬ: Чтобы привести пример видов отдельных вещей, которые мы должны охватить:
- Конкретная версия RPOS-репозиториев CentOS, определяемая по времени, когда она синхронизировалась из Интернета
- Файлы конфигурации Nagios для установки в виртуальную машину после установки пакетов Nagios
- Сценарии кикстарта, используемые для создания виртуальных серверов
- Сценарии, используемые для запуска развертывания систем
- Наборы правил iptables, применяемые к каждому типу виртуальной машины
Меня не интересует, как все это делается в малейшей степени, более подробно, как мы представляем представление о том, какая версия каждой из этих вещей требуется во время развертывания.
[РЕДАКТИРОВАТЬ] OK, Все это сводится к тому, что я не очень разбираюсь в версиях SVN.Так как номер ревизии распространяется на весь репозиторий, все проекты неявным образом покрываются ... никакой реальной работы не требуется для достижения того, чего я хотел.Спасибо, и неудивительно, что я не имел никакого смысла для кого-либо еще ..