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