Subversion был разработан с использованием абстрактного сетевого уровня. Это означает, что на программном уровне для доступа к хранилищу может быть использован любой тип сервера, а «клиентский API для доступа к хранилищу» дает программистам возможность создавать плагины, которые будут взаимодействовать с соответствующим сетевым протоколом. Теоретически, Subversion может использовать неограниченное количество сетевых реализаций. Практически же, на данный момент есть только два сервера.
Apache — наиболее популярный web-сервер; при использовании модуля mod_dav_svn Apache получает возможность доступа к хранилищу, а так же делает его доступным для клиентов, используя протокол WebDAV/DeltaV, который является расширением HTTP. В другом углу ринга — svnserve — небольшой, самостоятельный сервер, использующий для связи с клиентами собственный протокол. В Таблица 6.1, «Сравнение серверов» дано сравнение этих двух серверов.
Таблица 6.1. Сравнение серверов
| Возможность | Apache + mod_dav_svn | svnserve |
|---|---|---|
| Настройки установления личности | стандартное установление личности средствами HTTP(S), сертификаты X.509, LDAP, NTLM, а также другие механизмы, доступные для использования в Apache | CRAM-MD5 или SSH |
| Настройки пользовательских учетных записей | внутренний файл 'users' | внутренний файл 'users' или использование существующих системных (SSH) учетных записей |
| Настройки прав доступа | доступ на чтение/запись устанавливается сразу на всё хранилище, или настраивается по-каталогово | доступ на чтение/запись устанавливается сразу на всё хранилище, или настраивается по-каталогово |
| Шифрование | через SSL (опционально) | через SSH-туннель (опционально) |
| Logging | full Apache logs of each HTTP request, with optional «high-level» logging of general client operations | no logging |
| Интероперабельность | частично, используя другие WevDAV-клиенты | только для svn клиентов |
| Просмотр через веб | ограниченная встроенная поддержка, или использование программ сторонних разработчиков, таких, как ViewVS | только при помощи программ сторонних разработчиков, таких, как ViewVS |
| Скорость | более низкая | более высокая |
| Начальная установка | несколько сложная | достаточно простая |
Установите и настройте сервер Apache 2.0, затем активируйте модуль сервера subversion. Клиенты будут обращаться к серверу через HTTP или HTTPS, используя протокол WebDAV.
Subversion может использовать любой из механизмов аутентификации, интегрированный в Apache.
Нет нужны создавать учётные записи на сервере.
Ведение логов средствами Apache.
Возможность шифровать трафик с помощью SSL.
Если компьютер или сеть защищены брандмауэром, порты HTTP(S) обычно открыты.
Встроенный просмотр хранилища через веб-обозреватель.
Хранилище может быть смонтировано как сетевой диск. (Смотрите «Autoversioning».)
Скорость заметно ниже, чем при использовании svnserve.
Первичная настройка более комплексная.
"Лёгкий" процесс, который может работать как самостоятельно, так и "по вызову" inetd. Аутентификация происходит по алгоритму CRAM-MD5. Используется свой протокол.
Быстрая и лёгкая установка.
Сетевой протокол более продвинутый и работает ощутимо быстрее, чем WebDAV.
Нет необходимости создавать на сервере дополнительные учётные записи.
Пароль не передаётся по сети.
Протокол не поддерживает шифрование.
Доступен только один метод аутентификации.
Пароль хранится на сервере открытым текстом.
Логи не ведутся, даже лог ошибок.
Клиент подключается к серверу с помощью SSH, используя системную учётную запись. При этом на сервере запускается временный процесс svnserve. Он работает с хранилищем, обменивается данными с клиентом через SSH-туннель, после чего, при закрытии SSH-сессии, завершается. (При этом методе в системе не будет постоянно запущенных процессов svnserve).
Используемый stateful-протокол значительно быстрее, чем WebDAV.
Удобство использования существующих учётных записей и пользовательской инфраструктуры.
Весь сетевой траффик шифруется.
Only one choice of authentication method.
No logging of any kind, not even errors.
Requires users to be in same system group, or use a shared ssh key.
Can lead to file permissions problems.
So, which server should you use? Which is best?
Obviously, there's no right answer to that question. Every team has different needs, and the different servers all represent different sets of tradeoffs. The Subversion project itself doesn't endorse one server or another, or consider either server more «official» than another.
In general, the authors of this book recommend a vanilla svnserve installation for small teams just trying to get started with a Subversion server; it's the simplest to set up, and has the fewest maintenance issues. Remember, you can always switch to a more complex server deployment as your needs change.
Here are some general recommendations, based on years of supporting users:
If you're trying to set up the simplest possible server for your group, then a vanilla svnserve installation is the easiest, fastest route. Note, however, that your repository data will be transmitted in the clear over the network. If your deployment is entirely within your company's LAN or VPN, this isn't an issue. If the repository is exposed to the wide-open internet, then you might want to make sure the repository's contents aren't sensitive (e.g. it contains only open-source code.)
If you need to integrate with existing identity systems (LDAP, Active Directory, NTLM, X.509, etc.), then an Apache-based server is your only real option. Similarly, if you absolutely need server-side logs of either server errors or client activities, then an Apache-based server is required.
If you've decided to use either Apache or stock
svnserve, create a
single svn user on your system, and
run either Apache or svnserve as that user. Be sure to
make the repository directory wholly owned by
the svn user as well. These keeps the
repository data nicely siloed and protected by operating
system filesystem permissions, changeable by only the
Subverion server process itself.
If you have an existing infrastructure heavily based on SSH accounts, and if your users already have system accounts on your server machine, then it makes sense to deploy an svnserve-over-ssh solution. Otherwise, we don't recommend this option to the general public. It's generally considered safer to have your users access the repository via (imaginary) accounts managed by svnserve or Apache, rather than by full-blown system accounts. If your deep desire for encrypted communication still draws you to this option, we recommend using Apache with SSL instead.
Do not be seduced by the simple
idea of having all of your users access a repository
directly via file:/// URLs. Even if
the repository is readily available to everyone via
network share, this is a bad idea. It removes any layers
of protection between the users and the repository: users
can accidentally (or intentionally) corrupt the repository
database, it becomes hard to take the repository 'offline'
for inspection or upgrade, and it can lead to a mess of
file-permissions problems (see
«Supporting Multiple Repository Access Methods».) Note
that this is also one of the reasons we warn against
accessing repositories via svn+ssh://
URLs — from a security standpoint, it's effectively
the same as local users accessing
via file:///, and can entail all the
same problems if the administrator isn't careful.)