В один прекрасный день мне надоело заливать по ftp\ssh все изменения, внесённые в проект. К этому моменту я уже вынашивал идею перенести разработку под управление SVN — контроль версий, всё-таки приятная штука. В итоге было решено совместить приятное с полезным — и контроль версий, и автоматическое обновление проекта. По традиции — повествование будет вестись на примере моего любимого debian'a.
Заметку можно считать дополнением статьи
svn tips (по крайней мере — первого пункта).
Про установку\настройку SVN можно почитать в следующих топиках:
Создаём init-скрипт, для запуска svn-сервера с системой (изначально — скрипт был найден где-то на просторах интернета. вроде бы, я в нём что-то менял :) ).
/etc/init.d/svn:
#!/bin/sh -e
#
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Get LSB functions
. /lib/lsb/init-functions
. /etc/default/rcS
SVNSERVE=/usr/bin/svnserve
SVN_USER=subversion
SVN_GROUP=www-data
SVN_REPO_PATH=/usr/share/svn/
# Check that the package is still installed
[ -x $SVNSERVE ] || exit 0;
case "$1" in
start)
log_begin_msg "Starting svnserve..."
umask 002
if start-stop-daemon --start --chuid $SVN_USER:$SVN_GROUP --exec $SVNSERVE -- -d -r $SVN_REPO_PATH
then
log_end_msg 0
else
log_end_msg $?
fi
;;
stop)
log_begin_msg "Stopping svnserve..."
if start-stop-daemon --stop --exec $SVNSERVE
then
log_end_msg 0
else
log_end_msg $?
fi
;;
restart|force-reload)
"$0" stop && "$0" start
;;
*)
echo "Usage: /etc/init.d/svn {start|stop|restart|force-reload}"
exit 1
;;
esac
exit 0
Дадим всем право на исполнение, настоятельно порекомендуем системе запускать svn при старте и заодно стартанём его:
chmod a+x /etc/init.d/svn
update-rc.d svn defaults
invoke-rc.d svn start
Настроим обновление рабочей копии при коммите — хук
/usr/share/svn/hooks/post-commit:
#!/bin/sh
exec > /tmp/svnup 2>&1
# весь вывод скрипта будет направлен в файл /tmp/svnup
for path in `svnlook dirs-changed /usr/share/svn | fgrep '/trunk/' | cut -d '/' -f 2- | sort -u`
# получаем список директорий, изменённых в коммите, отрезаем первую
# часть (в моей репе - /trunk) и, если такой путь есть — делаем там svn up
do
if [ -d "/var/www/$path" ]
then
echo $path
/usr/bin/svn up -N /var/www/$path
fi
done
Не забываем выдать право на исполнение:
chmod a+x /usr/share/svn/hooks/post-commit
А так же — проследить за тем, чтобы у пользователя subversion
:www-data были права на запись в необходимые каталоги
/var/www/$path.
Дальнейшая работе (обустройство репозитария) уже выполняется на машине разработчика (ну разве что — потом выгрузить рабочую копию на сервере в нужную папку).
И, как обычно, — надеюсь, что материал окажется кому-нибудь полезным.
_________
Текст подготовлен в
ХабраРедакторе
комментарии (60)
поиск:
habrahabr.ru/search/? q=svn+trac
вот неплохая версия:
habrahabr.ru/blogs/development/29440/
давеча даже распечатал с хабра одну из подобных статей. к сожалению, уже не помню, какую.
думаю, интереснее было бы почитать про svn+trac, т.к. svn поднимается достаточно просто… (например skazkin.habrahabr.ru/blog/29716/).
а еще есть интересные плаги:
для Visual Studio: VSTrac (для трака), и ankhsvn для SVN.
для Eclipse: Mylyn (для трака и JIRA), SVNKit для SVN собсно.
может, как add-in к статье)
Насчет «в различных разработках применяются тулзы, которые удобнее для данной разработки», все перечисленные инструменты служат одной цели — версионный контроль. И удобство можно лишь оценивать по большим или меньшим возможностям работы с версиями. Вот тут гит все мейнстримныe vcs и опережает на голову.
* ушёл читать добро от тов. los_t.
то что нужно. читаю..)
SVN тоже умеет
я пишу на c# в данный момент. использую VS. для работы использую плаг для VS->SVN. когда работаю под Eclipse, использую плаг для Eclipse. вот вам и удобства в разработке. если кому нравится работать отдельным интерфейсом — пусть юзает Git. я достаточно долго выбирал оптимальный для себя вариант. SVN оказался найудобнейшим.
кроме всего, «более широкие возможности» — очень сильно звучит. опишите поподробнее, т.к. аргументации я по-прежнему не увидел. и «опережения на голову» также не вижу… под винду смотрел git. я не впечатлен, по правде. сейчас посмотрю еще раз, дабы не быть субъективным…
Не стоит забывать что все большее количество разработчиков (особенно под web) мигрируют с windows на альтернативные OS. Я работаю на Leopard+Textmate и пользуюсь консольным интерфейсом git. В свое время активно пользовался и VS и Eclipse поэтому знаю о чем говорю — консольный интерфейс при грамотном использовании не менее эффективен чем виндовые поделки.
2. Напоминает старый анекдот:
Приходит покупатель в магазин:
(покупатель)-У вас туалетная бумага есть?
(продавец)-Туалетной нет, есть наждачная, брать будете?
«установить на сервер» — вот более корректный вариант.
а это?..
Почему нельзя сразу сделать svn up в рабочей версии на сервере?
Или вы таким образом пытаетесь сделать оптимизацию — дескать если изменения не затронули trunk, то и не выкладывать?
И еще момет — по какому урлу рабочая версия лезет в репозитарий?
Есть подозрение, что процесс встанет на запросе пароля к репозитарию.
урл пошлый — svn://localhost. анонимусам чтение открыто.
* может работать с более чем одним проектом
* блокирует\пытается обновить только те каталоги, в которые были внесены изменения (т.о. время коммита уменьшается)
* не требует перекомпиляции после внесения в него изменений :)
Апдейт с локального сервера 350 мегабайт бинарных данных (из них изменено около 150) занимает около 1.5—2.5 секунд. У Вас столько исходников есть? (на текстовые данные делается diff и передается уже он).
Чем порочна? Само собой не надо выкладывать на рабочий сервер, а только на тестовый — думаю в этом плане как раз удобно. Закоммитил, протестировал проект целиком.
На этот случай ведь можно распилить репозиторий на 2 части: собственно для закидывания коммитов и для отлаженных участков… У меня подобных проблем пока не возникало — над проектом один работаю, так что не задумывался над этой проблемой.
Дома на досуге обязательно поковыряю… кхе… осталось дождаться досуга :)
спасибо.
Для этого хватит svn+ssh:// который работает куда приятнее. + есть возможность использовать ключ -c, который включает компрессию на ssh-тунель.
Один-два человека прекрасно могут работать с svn'ом через ssh и не нагружать сервер лишним демоном (светить открытый порт).
NB. Напишите, пожалуйста, про права доступа к репозитарию. Этот момент в статье не освещен и многие могут просто не подумать об этом. Результатом будет куча репозитариев с анонимным чекаутом.
Про права доступа написано в статье «Установка и настройка SVN (сервер+клиент)», надеюсь интересующийся народ таки обратит внимание.
Использую SVN (+tortoiseSVN) и очень доволен. Но не везде есть доступ к шеллу и установлен SVN.
Возможно кто-то в курсе тулзы, которая бы делала то же самое что и SVN, только с помощью залитых на сервер ПХП скриптов или(и) FTP протокола.
И у коллеги, что слева от меня.
Конечно я пробовал текстмейт. И в свое время из-за него перешел на Mac.
Но вот парадокс.
BTW, я на мак изначально тоже из-за текстмейта пересел :)
Но для домашних/одиночных разработок я в конце концов счёл его несколько избыточным и остановился на Norton GoBack и т.п. утилитах, делающих журналирование всех изменений файловой системы с возможностью отката/восстановления отдельных файлов.
И мне лично не понятно, что там такого «тяжёлого», что вместо использования специального софта извращаются с FTP, системами бекапа файлов и т.д. Для создания локального репозитория вообще же не надо устанавливать никакой сервер и т.д., средствами того же TortoiseSVN делается в пару кликов.