Производительность протокола Subversion

Question

Я только начал знакомиться с Subversion и мне было интересно Какой протокол обеспечивает наилучшую производительность файла: // или svn: // при доступе к хранилищу Subversion по сети? Если мы не используем протокол svn: //, будут ли упущены какие-либо функции, которые мы не могли бы смягчить, используя протокол file: //? Мы все в одном домене NT и планируем использовать проверку подлинности Windows и использовать безопасность NTFS / UNC.

ТИА!

Answer 1

Книга SVN рекомендует, чтобы вы не использовали файл: // протокол для нескольких пользователей

Выбор конфигурации сервера :

Не поддавайтесь простому представлению о том, что все ваши пользователи имеют доступ к хранилищу напрямую через URL-адрес file: //. Даже если репозиторий легко доступен всем через сетевой ресурс, это плохая идея. Он удаляет любые уровни защиты между пользователями и хранилищем: пользователи могут случайно (или намеренно) повредить базу данных хранилища, становится трудно перевести хранилище в автономный режим для проверки или обновления, и это может привести к путанице в проблемах с разрешениями файлов ( см. раздел «Поддержка нескольких методов доступа к репозиторию»). Обратите внимание, что это также одна из причин, по которой мы предостерегаем от доступа к репозиториям через svn + ssh: // URLs - с точки зрения безопасности, это практически то же самое, что локальные пользователи, получающие доступ через file: //, и это может повлечь за собой те же проблемы если администратор не внимателен

Answer 2

Если вы хотите использовать аутентификацию Windows, используйте протокол http (s) вместе с apache. Это немного сложнее в настройке, и не обязательно быстрее, но позволяет вам использовать стандартные методы аутентификации Apache для аутентификации. Включая различные схемы проверки подлинности на основе Windows или Kerberos.

Btw. Обычно скорость протокола не зависит от скорости SVN. Svn кэширует информацию на диске, поэтому большинство обычных действий основаны на локальном кэше. Затем коэффициент скорости находится в репозитории, а полоса пропускания сети, а не в протоколе.

Answer 3

Оформление / обновление через svn: // примерно в 4-12 раз быстрее, чем через http (s): //. Коэффициент зависит от количества файлов / папок и размера файла. Apache намного медленнее для многих маленьких файлов, потому что каждый файл представляет собой полный цикл http-запрос-ответ. В черепахе вы можете легко увидеть снижение скорости:

Оформление больших java-проектов. Если вы перенесете огромный .jar, передача увеличится, при получении исходных java-файлов и создании структуры пакета он упадет.

Также важно, что svn checkout медленнее на клиенте, чем svn export , а также затмение (java) намного медленнее, чем черепаха / CMD.

Answer 4

Я согласен с другими, что svn: // намного быстрее, чем http: //. При этом я использую http: // в своих репозиториях, потому что мне нравится файл контроля доступа mod_authz_svn, и я еще не обновился до 1.5.

Поскольку мой основной репозиторий огромен, мы поддерживаем svn: // запущенным только для чтения. Я предлагаю пользователям сделать первоначальную проверку как svn: //, а затем использовать svn relocate, чтобы превратить ее в http: // url для фиксации. Обновления на svn: // запускаются в приемлемое для нас время.

Answer 5

Как утверждает Поль де Вриз, протокол, используемый SVN, не повлияет на производительность так же, как другие факторы. Если вы находитесь в небольшой локальной сети, тогда протокол SVN может быть вам удобен. Во всех остальных случаях лучше всего использовать HTTP: // с Apache. Я был в локальных сетях, где производительность SVN: // хуже, чем HTTPS: // подключений к Интернету.

Вы также найдете Apache, вероятно, более управляемым решением с точки зрения безопасности или просмотра SVN-репозитория.