Почему стоит выбрать mod_dav_svn вместо svnserve и обозревателя хранилища?

Question

Пожалуйста, исправьте меня, если я ошибаюсь в своем понимании mod_dav_svn, которое заключается в том, что он в основном служит 2 целям:

1. Предоставление хранилища SVN (в файловой системе) клиентам, что может быть:
   • обозреватели хранилища (например, веб)
   • сама команда 'svn', которая является программой командной строки клиента
2. Действует как обозреватель хранилищачтобы сделать репозиторий удобным для просмотра

Теперь для пункта 1 верны ли мои следующие предположения?

• Каждый раз, когда репозиторий открывается с помощью mod_dav_svn, http:// или https:// используется форма доступа к хранилищу
• При использовании svnserve используется форма svn: // доступа к хранилищу
  • В этом случае mod_dav_svn не будет использоваться дополнительно

Для пункта 2, если используется функция просмотра хранилища Trac, нет никакого дополнительного использования дляфункционал просмотра репозиторияЧто предлагает mod_dav_svn?

Служит ли mod_dav_svn какой-либо другой цели, которую я здесь не обозначил?Если спросить по-другому, есть ли какой-то недостаток в использовании svnserve и Trac?

Я спрашиваю, потому что у меня сложилось впечатление, что mod_dav_svn очень часто используется, поэтому мне интересно, что я пропускаю.

Answer 1

Забудьте о точке № 2: просмотр HTTP.Это просто небольшой бонус.Это не заменяет вашу потребность в чем-то вроде Рыбий глаз , ViewVC или (мой любимый) Sventon .

Есть некоторые недостаткииспользуя Apache http для вашего сервера Subversion:

• Это медленнее
• Сложнее настроить

Тогда есть свои преимущества:

• Используется стандартный порт (80), который обычно не блокируется брандмауэрами.
• Он может быть интегрирован с LDAP и Active Directory
• Вы можете использовать HTTPS , которыйбудет шифровать обновления и извлечения (включая пароли пользователей).
• Вы можете иметь несколько репозиториев, использующих один и тот же экземпляр Apache httpd.С svnserve вы можете создавать только один репозиторий на каждый экземпляр, и если у вас есть несколько репозиториев в одной системе, вам придется запускать каждый процесс svnserve на нестандартном порту.

Мое личное мнение: если вы работаете в корпоративной среде, преимущества использования протокола HTTP или HTTPS перевешивают недостатки.Если вы говорите о небольшом репозитории, а вы и ваши друзья, я запускаю svnserve просто из-за меньших накладных расходов и более легкой настройки.Однако в этих обстоятельствах я просто использую Github и не беспокоюсь об этом.

Я запускаю Subversion в качестве своей системы управления исходным кодом на своем компьютере и в этом случае использую svnserve.

---

Спасибо, некоторые последующие вопросы.1) Когда я получаю доступ к URL-адресу на моем svn-сервере как svn: // server / repo, разве это не порт 80?2) Если интеграция LDAP не может быть выполнена для svnserve, единственный способ, которым пользователи могут аутентифицироваться, - это если они находятся в файле, на который ссылается password-db в svnserve.conf для svn: //, или имеют учетную запись оболочки для svn+ SSH: //?3) Разве svn + ssh: // не может предложить такую ​​же защиту, которую предлагает https: //, или есть разница?(Извините, я не могу поместить абзацы здесь, он отправляет каждый раз, когда я нажимаю клавишу ввода, я делаю это правильно.) -

1. По умолчанию используется порт 3690.Это можно изменить, когда вы запустите svnserve, но тогда ваш svn URL тоже должен это отражать.

2. Практически верно.В большинстве мест, где используется svnserve, используется файл passwd.Однако, начиная с версии 1.5, вы можете использовать SASL .Однако я никогда не видел, чтобы кто-нибудь использовал его.

3. Да, ssh + svn: // действительно предлагает зашифрованные пакеты.Тем не менее, SSH может быть сложно реализовать.По сути, процесс svnserve должен быть запущен и запущен для этого конкретного пользователя.Это означает, что каждому пользователю необходим прямой доступ для чтения / записи к хранилищу.Вам нужно настроить umask для каждого пользователя и создать группу Subversion Unix, к которой принадлежит каждый.Затем, поскольку эти пользователи имеют прямой доступ к файлам репозитория, не позволяйте им входить на сервер репозитория. Онлайн-руководство содержит полную информацию.Но, в конце концов, он работает только на серверах Unix и клиентах Unix.Клиенты Windows не имеют SSH на них, и должны были бы установить это.Я пробовал это несколько раз, но https: // намного проще.

Answer 2

Простота svnserve делает его легким для быстрой и грязной установки, особенно если вы развертываете в Windows.

Однако, в тот момент, когда вам нужно запомнить много паролей, и хотелось бырепозиторий Subversion использует тот же механизм единого входа, который используется в организации, очень помогает использование механизмов аутентификации Apache в сочетании с mod_dav_svn.

До Subversion 1.7 работоспособность mod_dav_svn была ужасной и, как известно, медленнее, чем svnserve.Subversion 1.7 предположительно предлагает более быстрый и простой протокол HTTP, который должен сделать использование mod_dav_svn более приемлемым.