Установка сервера SVN

Question

[Robotex]

Приобрел VDS. Хочу поднять на нем SVN-сервер (или git). Причем есть некоторые особенности: svn будет использоваться для разработки web-проекта, следовательно корень репозитория должен быть корнем сайта и после коммита должен быть сразу доступен в браузере (причем хорошо бы разделятьрелизную версию на порту 80 и девелоперскую на 8080). Кроме того в этом же корневом каталоге лежит папка templates, с которой работает дизайнер. Так вот дизайнер должен иметь доступ только к этой папке, а программисты ко всем, включая эту (если это невозможно, то не проблема вынести папку в другое место, но все же хотелось бы так). Ну и наконец, если это возможно, то хотелось бы комиттить и базу данных (причем тоже иметь релизную и девелоперскую версии).

Вот только ума не приложу как подобное реализовать (никогда не поднимал системы контроля версий). Подскажете?

Answer 1

[ksusha]

>>корень репозитория должен быть корнем сайта и после коммита должен быть сразу доступен в браузере

Пожалуй, включу режим зануды и внесу некоторую ясность. Репозиторий — это не просто набор файлов и папок. Репозиторий subversion использует организованную особым образом файловую систему. Обычно файлы хранятся в БД, либо являются файлами определенного формата, так что корень репозитория не может быть корнем сайта.

Что касается использования файлов проекта по прямому назначению, нужно, во-первых, экспортировать рабочую копию(svn checkout). Это уже обычное дерево папок и файлов со скрытой поддиректорией .svn в каждом каталоге дерева. Такая локальная копия имеется у каждого участника проекта, который коммитит в центральный репозиторий. Но и эту копию нельзя использовать на продакшене, так как она содержит эти самые служебные поддиректории .svn. Для того чтобы от них избавиться, экспортируется чистая рабочая копия командой svn export. Вот теперь это ваш проект.

Сейчас как раз разрабатываю веб-проект с помощью svn, могу поделиться как у меня все устроено.
Есть VDS-ка, где крутится сервер svn. Есть две ветки репозитория — trunk и release. На локальном компе рабочая копия, по мере разработки коммичу все в trunk. Все скрипты тестирую на локалхосте. Девелоперская база данных общая, расположена на том же серваке что и svn.

Comments

[VBart]

Никто не мешает закрыть доступ к .svn средствами веб-сервера.

[ksusha]

Это просто хороший тон и избавляет от случайностей, которые могут закончиться печально. Можно поменять веб-сервер и забыть прописать ограничение в конфиге, да еще много чего. Если svn дает такую возможность, почему бы не воспользоваться? Не вижу смысла вставлять костыли там, где можно обойтись без них.

[VBart]

Весьма спорно. То, что находится в пределах видимости веб-сервера и так доступно пользователю, а это обычно всякие картинки, css-ки и js-ки. И самое печальное, что может быть, это любопытный пользователь получит историю изменений этой самой css-ки. И да, веб-сервер вы конечно часто меняете, и всякий раз, когда это случается, относитесь к настройке крайне халатно.

Не надо преувеличивать. Иногда делать checkout просто удобней, чем export. Последний всегда ведет к копированию всех данных, а не только изменений.

[VBart]

Это я даже спросонья погорячился. Разумеется даже никакой истории изменений в папках ".svn" не хранится. Там только неинтересные служебные данные, значения свойств и оригинальные версии файлов, которые будут совпадать с теми, что и так доступны пользователю. В общем, вообще ничего интересного и секретного.

Answer 2

[DevMan]

корень репозитория должен быть корнем сайта

это бред.

после коммита должен быть сразу доступен в браузере

хук на комит, и у вас в document root лежат свежие файлы.

Рулёжка доступом различных групп к различным директориям в случае git элементарно решается при помощи gitolite.

Про SVN не подскажу, уже забыл что это такое.

Answer 3

[Ogra]

1. Мухи отдельно, котлеты отдельно
Корень репозитория не должен являться корнем сайта. У репозитория должна быть своя структура — с ветками, и т.д.

2. Автоматическое обновление
Ставится post-commit хук, который после каждого коммита будет обновлять сайт. Ничего сложного в этом нету, документация в инете есть.

3. Данные
Тут уже потребуется написать пару скриптов — для снятия дампа, и для его обновления. Также может понадобиться скрипт, которые снимает лишь частичный дамп — критичный для приложения. Возможно, наилучшим решением будет специальный софт, поддерживающий БД в актуальном состоянии.

Answer 4

[xSus]

Тут не хватает ключевого слова Continuous Integration она же непрерывная сборка. т.е. нужен промежуточный софт, который в автоматическом режиме (или по нажатию одной кнопки) развернет сайт на нужном порту. Т.е. в вашем случае, я бы порекомендовал настроить два таких скрипта: первый по коммиту разворачивает и перезапускает сайт на девелоперском порту, а второй на «боевом» 80. Примерами таких серверов могут быть CruiseControl, Hudson…
т.е. для каждого сайта будет свой каталог и уж на них можно настраивать апач или иис…
Думаю дальше сами раскрутите решение своей задачи по ключевым словам?

Comments

[Александр]

использую скрипт сборки конфигов, после исходников развертывания на продакшене
запускается скрипт, который генерит специфичные конфиги для каждого хоста. ( хосты: devel, notebook, prodaction)

С БД чуть посложнее, использую mySqlDiff и храню различия БД

[Александр]

запускаю скрипт (все в одном скрипте, параметры разные), который развертывает/откатывает изменения БД