Существует четыре общих протокола для доступа к сети SVN.
svn://repos
svn+ssh://repos
https://repos
http://repos
Страница Википедии не говорит о различиях четырех разных протоколов. Я всегда предпочитал svn://, потому что это проще всего настроить, но в чем разница, а какая - лучше?
http:// имеет серьезные накладные расходы, особенно при работе с тысячами небольших файлов. Я использовал svn для сайта, на котором было около 50 000 значков, все сохраненные в SVN. С помощью HTTP на проверку потребовалось около 20 минут. Как только я переключился на svn://, потребовалось меньше минуты. Это связано с тем, что с HTTP это один новый HTTP-запрос на файл.
http:// однако имеет следующее большое преимущество: он обычно проходит через брандмауэры. Например, теперь, когда я переключился на svn://, я больше не могу обращаться к своему репозиторию из своего университета из-за своего брандмауэра.
Относительно разницы между использованием SSL/TLS или нет, это очевидно: данные зашифрованы; однако его сложнее настроить.
svn+ssh - это протокол svn, выполняемый внутри туннеля SSH. Клиент использует SSH для входа на удаленный сервер и удаленно запускает команду svn в этом туннеле. На мой взгляд, svn+ssh - это самый простой способ использования репозитория subversion в удаленной системе, потому что у вас нет сервера для запуска в этой системе, предполагая, что у вас уже есть сервер SSH.
Кроме того, svn+ssh выигрывает от криптографической защиты SSH. Не используйте протокол raw svn по ненадежным сетям.
Основная проблема с svn+ssh заключается в том, что для доступа к удаленному компьютеру требуется доступ к оболочке. Трудно предложить кому-либо доступ к репозиторию, не предоставляя ему доступ ко всей учетной записи оболочки. Для этого вам нужен один из HTTP-методов, т.е. http или https (желательно https из-за уровня шифрования и аутентификации). Эти методы сложнее конфигурировать (вам нужен сервер HTTP/HTTPS, например Apache), но разрешить администратору репозитория тщательно и точно контролировать права доступа к репозиторию.
https:// и svn+ssh:// зашифрованы и поэтому безопасны для передачи защищенных данных (например, вашего пароля SVN.
Если это что-то вроде Git, svn+ssh:// будет быстрее, чем https://, а svn:// будет быстрее, чем http://.
Также, если вы используете http://(Apache + SVN), вы можете заставить своих пользователей регистрироваться с помощью проверки подлинности Windows с добавлением модуля mod_auth_sspi.
Смотрите здесь: http://blog.pengoworks.com/index.cfm/2007/11/1/Configuring-Windows-Authentication-with-Apache-22x-and-Subversion
Таким образом, ваши (оконные) разработчики должны помнить только одного пользователя/пароля
http и https обрабатываются модулем веб-сервера для поддержки Subversion, поэтому вы можете использовать HTTP-аутентификацию (настроенную через .htaccess) для ограничения доступа к вашему репозиторию).
Можно сказать, что 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 для получения дополнительной информации: fooobar.com/info/98349/....