Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
вообще желлательно на продакшн заливать только какие либо теги… которые 100% стабильно, а вливать каждую ревизию я считаю не очень рационально.
если вливается очередной тег, то можно и все файлы обновить
если вливается очередной тег, то можно и все файлы обновить
Абсолютно согласен, что закачка на сервер это серьезная задача, но когда надо быстро исправить баг, мой скрипт может сохранить кучу времени и нервов
во всем проектах где я участвовал на продакшн машинах было
svn co /branches/stable/
все разработки ведуться в отдельных ветках, в stable только багфиксы — они раз в сутки «поднимаются» в другие ветки, таким образом обновить продакшн можно просто через
svn update
svn co /branches/stable/
все разработки ведуться в отдельных ветках, в stable только багфиксы — они раз в сутки «поднимаются» в другие ветки, таким образом обновить продакшн можно просто через
svn update
наш svn не доступен с инета
а как же .svn/?
там достаточно служебной информации, которая на продакшне явно лишняя.
там достаточно служебной информации, которая на продакшне явно лишняя.
А для копирования и перемещения файлов использовали svn copy и svn export?
Просто мне показалось, что это не очень удобно, особенно когда при выгрузке на продакшн нужно еще делать манипуляции с js и css (сливать в один, минифаить...).
Но как простой способ обновить файлы на продакшне, с учетом их последней стабильной версии, вполне подходит.
Просто мне показалось, что это не очень удобно, особенно когда при выгрузке на продакшн нужно еще делать манипуляции с js и css (сливать в один, минифаить...).
Но как простой способ обновить файлы на продакшне, с учетом их последней стабильной версии, вполне подходит.
все эти процессы автоматизируются, ровно как и апдейт структуры бд.
говорю из опыта обновления софта _одновременно_ на 8 продакшн серверах (у svn) в этом смысле божественно много настроек; у приличных людей, кстати, вся статика живёт отдельно от кода
говорю из опыта обновления софта _одновременно_ на 8 продакшн серверах (у svn) в этом смысле божественно много настроек; у приличных людей, кстати, вся статика живёт отдельно от кода
Отдельно от кода, на другом сервере? При небольшой нагрузке в этом нет смысла.
А вот получить неудобства из-за копирования директорий вместе с .svn/ можно.
А вот получить неудобства из-за копирования директорий вместе с .svn/ можно.
расскажите мне хотя бы один сценарий, где на продакшн машине нужно что-либо куда-либо копировать?
Ну если не рассматривать статику, которую периодически приходится копировать, а на нее я уверен у вас стоит svn:ignore, то будем говорить только непосредственно о коде.
У нас ядро фреймворка вынесено в отдельный каталог и используется всеми проектами, назовем его core/.
Так же у каждого проекта есть свой app/ и htdocs/. При разработке получается следующая структура каталогов относительно документ_рута:
../../core
../app
htdocs
У каждого проекта свой сервер, соответственно на продакшне структура каталогов другая:
../core
../app
htdocs
Вот тут мы и копируем ядро на уровень ниже. Если бы там были .svn, то уже речь о svn update бы не шла.
При этом я уверен, что при вашей архитектуре, это может быть оправдано, если вы уже столь долгое время так работаете.
У нас ядро фреймворка вынесено в отдельный каталог и используется всеми проектами, назовем его core/.
Так же у каждого проекта есть свой app/ и htdocs/. При разработке получается следующая структура каталогов относительно документ_рута:
../../core
../app
htdocs
У каждого проекта свой сервер, соответственно на продакшне структура каталогов другая:
../core
../app
htdocs
Вот тут мы и копируем ядро на уровень ниже. Если бы там были .svn, то уже речь о svn update бы не шла.
При этом я уверен, что при вашей архитектуре, это может быть оправдано, если вы уже столь долгое время так работаете.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Решаем проблему с svn: Revision range is not allowed