Зачем выбирать mod_dav_svn вместо svnserve и браузера репозитория?

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

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

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

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

В пункте 2, если использовать функцию просмотра репозитория Trac, нет никакой дополнительной пользы для функций просмотра репозитория, предлагаемых mod_dav_svn?

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

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

Ответы

Ответ 1

Запуск точки # 2: просмотр HTTP. Это просто небольшой бонус. Это не заменит вашу потребность в чем-то вроде Fisheye, 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) Не может ли такая же защита, предлагаемая https://быть предложена svn + ssh://, или есть разница? (Извините, я не могу поставить абзацы здесь, он отправляется каждый раз, когда я нажимаю кнопку ввода, я делаю это правильно.) -

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

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

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

Ответ 2

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

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

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