Comments 11
> В наше время уже мало кто пользуется ftp, на смену пришли более удобные вещи, такие как svn
Каким образом svn является альтернативой для ftp?
Каким образом svn является альтернативой для ftp?
оч. просто. Ставите svn, его транк является корнем www сервера. Т.е. при любом коммите мы тут же имеет новую версию на www.
промахнулся. Коммент ниже.
оффтоп:
кажись дерево комментов опять порушилось… Эх, хабр, хабр…
кажись дерево комментов опять порушилось… Эх, хабр, хабр…
Спасибо Вам от параноика. =)
Спасибо за второй пример.
Хочется сделать небольшие, но, как мне кажется, полезные дополнения к способам передачи файлов
Если нужен защищенный способ передачи файлов, и не хочется отказываться от возможностей, предоставляемых svn, то можно воспользоваться доступом через svn+ssh. В этом случае клиент соединяется с сервером через SSH, запускает на серверной стороне svnserve, и теперь все данные между клиентом и сервером передаются по защищенному протоколу. Процесс аутентификации также перекладывается на плечи SSH-демона. Этот способ достаточно кратко (и мне кажется, даже чересчур кратко) описан в SVN book.
Кстати, через svn+ssh умеет работать и TortioseSVN, достаточно при инициализации репозитория вручную набрать протокол svn+ssh://user@host/full/path/to/repo/.
> Ставите svn, его транк является корнем www сервера. Т.е. при любом коммите мы тут же имеет новую версию на www.
Некоторые могут подумать, что имеется в виду "сделайте svn checkout своего проекта в корне сервера". Такая вещь крайне опасна, т.к. эта команда создает служебный каталог .svn с файлами text-base/FILENAME.svn-base, а вы ведь не хотите, чтобы исходники ваших скриптов были доступны любому желающему через веб... Для решения этой проблемы можно ограничивать доступ к каталогу .svn с помощью .htaccess или других средств веб-сервера, а ещё лучше хранить рабочую копию отдельно, а в корень www делать "svn export" по необходимости.
Если нужен защищенный способ передачи файлов, и не хочется отказываться от возможностей, предоставляемых svn, то можно воспользоваться доступом через svn+ssh. В этом случае клиент соединяется с сервером через SSH, запускает на серверной стороне svnserve, и теперь все данные между клиентом и сервером передаются по защищенному протоколу. Процесс аутентификации также перекладывается на плечи SSH-демона. Этот способ достаточно кратко (и мне кажется, даже чересчур кратко) описан в SVN book.
Кстати, через svn+ssh умеет работать и TortioseSVN, достаточно при инициализации репозитория вручную набрать протокол svn+ssh://user@host/full/path/to/repo/.
> Ставите svn, его транк является корнем www сервера. Т.е. при любом коммите мы тут же имеет новую версию на www.
Некоторые могут подумать, что имеется в виду "сделайте svn checkout своего проекта в корне сервера". Такая вещь крайне опасна, т.к. эта команда создает служебный каталог .svn с файлами text-base/FILENAME.svn-base, а вы ведь не хотите, чтобы исходники ваших скриптов были доступны любому желающему через веб... Для решения этой проблемы можно ограничивать доступ к каталогу .svn с помощью .htaccess или других средств веб-сервера, а ещё лучше хранить рабочую копию отдельно, а в корень www делать "svn export" по необходимости.
svn+ssh штука хорошая, но это именно тот ssh тоннель, о котором я и рассказал. Тот же TortioseSVN просто реализует его автоматом, как и SQLYog для мускуля.
Я лишь рассказал принцип и «ручную работу», без обзора автоматических клиентов.
Насчет /.svn/ вы хорошо подметили, но данная штука сработает если установлен svnserve, а не модуль к апачу (ибо это там предусмотрено). В иных же ввв серверах все тоже не так просто. Например я юзаю nginx везде, у меня простой regexp при обработке урла — все что не статика (.js, .css, .xml, .jpg итп), то скрипт, а значит нужно передать uri на растерзание fast-cgi. Хотя это лишь частный случай, подметили вы верно.
Я лишь рассказал принцип и «ручную работу», без обзора автоматических клиентов.
Насчет /.svn/ вы хорошо подметили, но данная штука сработает если установлен svnserve, а не модуль к апачу (ибо это там предусмотрено). В иных же ввв серверах все тоже не так просто. Например я юзаю nginx везде, у меня простой regexp при обработке урла — все что не статика (.js, .css, .xml, .jpg итп), то скрипт, а значит нужно передать uri на растерзание fast-cgi. Хотя это лишь частный случай, подметили вы верно.
Sign up to leave a comment.
«Опасная» паранойя