Использование контроля версий с неиерархическим кодом?

Question

Я смотрю, как поместить базу кода, которая запускает несколько веб-сайтов, в систему управления версиями. Существует несколько экземпляров этой кодовой базы, где веб-сайты работают на разных виртуальных серверах.

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

Например, каждый экземпляр имеет каталог

/www/smarty/libs/plugins/

Где вы найдете специфичные для сайта функции для smarty. Когда мы будем готовы поместить его в систему управления версиями, папка /www станет корневой.

Таким образом, один из вариантов заключается в том, чтобы все специфичные для сайта функции распространялись на все сайты. Я не вижу проблемы самой по себе, но это кажется архитектурно «неправильным». Там будет куча файлов, которые принадлежат только одному развертыванию.

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

Какой лучший способ сделать это? Система контроля версий, которую мы рассматриваем, - это подрывная деятельность.

Answer 1

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

Как насчет того, чтобы каждый из нужных вам проектов и каталогов был представлен один раз в системе управления версиями. Затем, в отдельном каталоге (возможно, под названием /build/), есть различные конфигурации конфигурации. У вас может быть файл ant, который создает каждый сайт, или maven. Или вы можете использовать такие инструменты, как Capistrano или Fabric , чтобы иметь больше контроля над каждым развертыванием.

Answer 2

Вам не хватает шага "сборки", который позволил бы взять источник в систему контроля версий и создать пакеты развертывания для разных сайтов.Требуется только один исходный пакет, разные конфигурации сборки создают разные пакеты развертывания.Не пытайтесь напрямую поместить набор элементов управления в источник управления, это не источник!

Answer 3

С Subversion у вас может быть куча репозиториев:

• www находиться в общем хранилище
• plugins каждый будет в репозитории для конкретного сайта

Затем вложенные рабочие копии:

svn co http://www_repo www
cd www/smarty/libs
svn co http://foo_plugins_repo plugins

Подсказка: добавьте plugins к svn:ignore свойству www/smarty/libs

svn propset svn:ignore "plugins" www/smarty/libs

Конечно, вы могли бы сделать это и с git (через .gitignore), и, вероятно, с другими системами контроля версий, но я их не знаю.

(В качестве альтернативы вы можете пропустить часть вложенной рабочей копии (которая может испугать некоторых людей) и проверить вещи рядом, но использовать символическую ссылку вместо smarty/libs/plugins, в то время как ignore все еще относится)

Answer 4

Инструменты сделаны гибкими (как правило), поэтому вот несколько советов:

1. Большинство VCS 'позволяют игнорировать файлы и каталоги через некоторый механизм (например, Mercurial .hgигнорировать файл), так что вы должны иметь возможность выбирать то, что вы хотите / должны контролировать, а не то, что не должно быть.

2. Разделите файлы / каталоги на общий ресурсный проект и проекты, специфичные для сайтаа затем использовать систему сборки, чтобы интегрировать их для создания развертываемого пакета.Система сборки может быть такой же простой, как сценарий оболочки или более сложный фреймворк.Если это действительно простая интеграция, VCS может иметь некоторые базовые функции для объединения баз (например, Mercurial subrespositories).

Answer 5

Я считаю, что лучше всего создать каталог верхнего уровня в вашем хранилище для каждого сайта (Site-01, Site-02 и т. Д.), А внутри этих каталогов поместить дерево исходных текстов. Тогда вы можете оформить заказ отдельно. Я думаю, что приемлемо и несколько стандартно использовать один и тот же репозиторий для всех проектов, в которых участвует ваша компания.

Моя терминология может показаться нелепой, но я считаю, что основополагающая идея - это здравый смысл.