Какой протокол? svn://или http (s)://?

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

Можно сказать, что 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/....