Какой протокол? svn: / / или http (s)://?
существует четыре общих протокола для доступа к сети SVN.
svn://repos
svn+ssh://repos
https://repos
http://repos
страница в Википедии, не говорит много о различиях четырех различных протоколов. Я всегда предпочитал svn://, потому что это простой в настройке, но в чем разница и какой из них "лучше"?
6 ответов:
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. Не используйте rawsvnпротокол за ненадежные сети.главная проблема
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
поэтому ваши (windows) разработчики должны помнить только одного пользователя / пароль
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 для получения дополнительной информации:https://stackoverflow.com/a/38499619/761095.
Comments