Какой протокол?svn: // или http (s): //? - PullRequest
59 голосов
/ 26 января 2010

Существует четыре общих протокола доступа к сети SVN.

svn://repos
svn+ssh://repos
https://repos
http://repos

На странице Википедии мало что говорится о различиях четырех разных протоколов. Я всегда предпочитал svn://, потому что его проще всего настроить, но в чем разница и какой из них «лучше»?

Ответы [ 6 ]

54 голосов
/ 26 января 2010

http:// имеет серьезные накладные расходы, особенно при работе с тысячами маленьких файлов. Я использовал svn для веб-сайта, на котором было около 50 000 иконок, все они сохранены в SVN. С HTTP, оформление заказа заняло около 20 минут. Как только я переключился на svn://, это заняло меньше минуты. Это связано с тем, что для HTTP это один новый HTTP-запрос на файл.

http:// однако имеет следующее большое преимущество: обычно проходит через брандмауэры. Например, теперь, когда я переключился на svn://, я больше не могу получить доступ к своему хранилищу из своего университета из-за их брандмауэра.

Что касается разницы между использованием SSL / TLS или нет, ну, это очевидно: данные зашифрованы; однако его сложнее настроить.

20 голосов
/ 26 января 2010

svn+ssh - это протокол svn, запускаемый в туннеле SSH. Клиент использует SSH для входа на удаленный сервер и удаленно запускает команду svn в этом туннеле. На мой взгляд, svn+ssh - это самый простой способ использовать хранилище Subversion в удаленной системе, поскольку у вас нет сервера для запуска в этой системе, при условии, что у вас уже работает SSH-сервер.

Кроме того, svn+ssh получает выгоду от криптографической защиты SSH. Не используйте необработанный протокол svn в ненадежных сетях.

Основная проблема с svn+ssh заключается в том, что требуется удаленный доступ к оболочке. Трудно предложить кому-либо доступ к хранилищу, не предоставив ему доступ ко всей учетной записи оболочки. Для этого вам нужен один из методов на основе HTTP, то есть http или https (предпочтительно https из-за уровня шифрования и аутентификации). Эти методы более сложны в настройке (вам необходим сервер HTTP / HTTPS, например, Apache), но позволяют администратору хранилища тщательно и точно контролировать права доступа к хранилищу.

5 голосов
/ 26 января 2010

https:// и svn+ssh:// зашифрованы и поэтому безопаснее для передачи защищенных данных (таких как ваш пароль SVN.

Если это что-то вроде Git, svn+ssh:// будет быстрее https:// и svn:// будет быстрее http://.

4 голосов
/ 08 августа 2016

Можно сказать, что svn:// или svn+ssh:// обеспечивают гораздо лучшую производительность и скорость, чем простой HTTP или безопасный HTTPS при доступе к репозиториям Subversion, но в настоящее время это не так. Хотя svn:// или svn+ssh:// быстрее, чем HTTP (S), разница не так велика, как в SVN 1.6 или более старых версиях.

Есть нет серьезных проблем с производительностью с HTTP (S) и современными клиентами и серверами Subversion 1.7+.

HTTP (S) доступ с Subversion 1.7 стал намного более производительным и особенно при сетевых подключениях с высокой задержкой благодаря HTTPv2 (не путайте с HTTP / 2!) . Subversion 1.8 переключен с libneon на libserf для доступа по HTTP (S) и libserf обеспечивает лучшую производительность, чем libneon.

Если есть какая-то проблема, которая, по вашему мнению, связана с производительностью HTTP (S) или Subversion, работающей через HTTP (S), вам следует выяснить, существуют ли в вашей сети какие-либо службы, которые замедляют работу HTTP (S). Основной причиной может быть антивирус, активный брандмауэр или прокси. Не говоря уже о неправильно настроенных сетевых настройках. И не забывайте использовать современные клиенты и серверы Subversion!

Думая о примере неправильной конфигурации сети, кажется, что существует довольно распространенная проблема, которая затрагивает клиентские компьютеры, работающие в отключенных сетях, которые не имеют доступа к сайту Центра обновления Windows (http://ctldl.windowsupdate.com/). Это критическая проблема, которая затрагивает широкий спектр системных служб, но конечные пользователи замечают и сообщают об этом при использовании клиентов Subversion через HTTPS. Проблема выглядит так, как будто она связана с производительностью, но это не так. Прочтите этот поток StackOverflow для получения дополнительной информации: https://stackoverflow.com/a/38499619/761095.

4 голосов
/ 26 января 2010

Кроме того, если вы используете http: // (Apache + SVN), вы можете заставить своих пользователей войти в систему с использованием аутентификации Windows с добавлением модуля mod_auth_sspi.

Смотрите здесь: http://blog.pengoworks.com/index.cfm/2007/11/1/Configuring-Windows-Authentication-with-Apache-22x-and-Subversion

Так что ваши (windows) разработчики должны помнить только один пользователь / пароль

3 голосов
/ 26 января 2010

http и https обрабатываются модулем веб-сервера для поддержки Subversion, поэтому вы можете использовать HTTP-аутентификацию (настроенную через .htaccess) для ограничения доступа к вашему хранилищу).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...