Наиболее гибкая из всех возможных установок Subversion - это установка на основе Apache. Хотя её несколько сложнее устанавливать и настраивать, она предлагает преимущества, которые другие серверы предоставить не могут:

Первое, что вам необходимо перед установкой Apache - это компьютер под управлением Windows 2000, Windows XP+SP1, Windows 2003, Vista или Server 2008.

Итак, вы установили Apache и Subversion, но Apache до сих пор не знает, как работать с клиентами Subversion, такими как TortoiseSVN. Для того, чтобы Apache знал, какой URL должен быть использован для хранилищ Subversion, вы должны отредактировать конфигурационный файл Apache (обычно c:\program files\apache group\apache2\conf\httpd.conf) при помощи любого текстового редактора (например, Блокнота):

Краткое объяснение того, что вы только что ввели:

Но это только пример. Есть ещё очень много возможностей того, что вы можете сделать с веб-сервером Apache.

Если вы используете указание SVNParentPath, тогда вам не надо изменять конфигурационный файл Apache каждый раз при добавлении нового хранилища Subversion. Просто создайте новое хранилище в той же папке, где и первое хранилище, и всё! В моей компании у меня есть прямой доступ к этой папке на сервере посредством SMB (обычный доступ к файлам в Windows). Поэтому я просто создаю там новую папку, выполняю команду TortoiseSVN TortoiseSVN → Создать здесь хранилище... и у нового проекта уже есть свой дом...

Если вы используете Subversion версии 1.3 или более поздней, вы можете использовать указание SVNListParentPath on для того, чтобы Apache создавал перечень всех доступных проектов при попытке открыть веб-обозревателем родительскую папку, а не конкретное хранилище.

Модуль mod_authz_svn позволяет детально управлять правами доступа, основываясь на именах пользователей и на путях в хранилище. Эта возможность доступна при работе с сервером Apache, а начиная с Subversion версии 1.3 она также доступна и в svnserve.

Файл для примера может выглядеть подобно этому:

[groups]
admin = john, kate
devteam1 = john, rachel, sally
devteam2 = kate, peter, mark
docs = bob, jane, mike
training = zak
# Default access rule for ALL repositories
# Everyone can read, admins can write, Dan German is excluded.
# Правило доступа по умолчанию для ВСЕХ хранилищ
# У всех есть права на чтение, у группы admin есть права на запись,
# у Dan German - нет допуска.
[/]
* = r
@admin = rw
dangerman =
# Allow developers complete access to their project repos
# Разрешить разработчикам полный доступ к хранилищам,
# содержащим их проекты
[proj1:/]
@devteam1 = rw
[proj2:/]
@devteam2 = rw
[bigproj:/]
@devteam1 = rw
@devteam2 = rw
trevor = rw
# Give the doc people write access to all the docs folders
# Предоставить пользователям, создающим документацию,
# доступ для записи к папкам с документацией (docs)
[/trunk/doc]
@docs = rw
# Give trainees write access in the training repository only
# Предоставить стажёрам доступ для записи только к
# учебному хранилищу
[TrainingRepos:/]
@training = rw

Заметьте, проверка каждого пути может быть очень затратной операцией, особенно в случае журнала ревизий. Сервер проверяет каждый изменённый путь в каждой ревизии на возможность чтения, что может повлечь существенные затраты времени для ревизий, затрагивающих большое количество файлов.

Аутентификация и авторизация - отдельные процессы. Если пользователь хочет получить доступ по какому-либо пути в хранилище, он должен удовлетворить обоим наборам требований: обычным требованиям аутентификации и требованиям авторизации из файла доступа.

Как вы могли уже заметить, вам необходимо сделать запись имя_пользователя/пароль в файле passwd для каждого пользователя отдельно. И если (в целях безопасности) вы желаете, чтобы ваши пользователи периодически меняли свои пароли, вы должны будете выполнять эти изменения вручную.

Однако, есть решение этой проблемы - по крайней мере, если вы обращаетесь к хранилищу из ЛВС с контроллером домена Windows: mod_auth_sspi!

Первоначально модуль SSPI был предложен Syneapps вместе с исходным кодом, но его разработка была остановлена. Впрочем, не отчаивайтесь: сообществом работа над ним была возобновлена, и было реализовано несколько улучшений. Теперь этот проект располагается на SourceForge.

Заметьте, что если вы производите аутентификацию при помощи SSPI, то вам больше не нужна строка AuthUserFile для определения файла паролей. Вместо этого Apache аутентифицирует ваши имя пользователя и пароль при помощи домена Windows. Дополнительно вам необходимо будет обновить список пользователей в файле доступа Subversion (svnaccessfile) для того, чтобы они и там указывались как ДОМЕН\имя_пользователя.

Возможно использование более одного поставщика аутентификации для хранилища Subversion. Для этого необходимо сделать каждый тип аутентификации не-авторитарным (non-authoritative), чтобы Apache проверял несколько поставщиков на подходящие имя_пользователя/пароль.

Обычный сценарий - использование двух поставщиков аутентификации: во-первых - домена Windows, во-вторых - файла passwd для предоставления возможности доступа к SVN пользователям, не зарегистрированным в домене Windows.

Вот пример полной конфигурации Apache для совмещённой аутентификации через домен Windows и файл passwd:

<Location /svn>
  DAV svn
  SVNListParentPath on
  SVNParentPath D:\SVN

  AuthName "Subversion repositories"
  AuthzSVNAccessFile svnaccessfile.txt

# NT Domain Logins.
  AuthType SSPI
  SSPIAuth On
  SSPIAuthoritative Off
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On

# Htpasswd Logins.
  AuthType Basic
  AuthBasicAuthoritative Off
  AuthUserFile passwd

  Require valid-user
</Location>

Хотя в Apache 2.2.x и есть поддержка OpenSSL, по умолчанию она отключена. Вам необходимо включить её вручную.

<Location /svn>
  DAV svn
  SVNParentPath D:\SVN
  SSLRequireSSL
  AuthType Basic
  AuthName "Subversion repositories"
  AuthUserFile passwd
#  AuthzSVNAccessFile svnaccessfile
  Require valid-user
</Location>

Прислано в список рассылки TortoiseSVN Найджелом Грином (Nigel Green). Спасибо!

В некоторых серверных конфигурациях вам может быть необходимо настроить один сервер, включающий 2 виртуальных SSL-узла: один для общего доступа через веб (не требующий клиентского сертификата), другой должен быть безопасным, с запросом клиентского сертификата, на котором и работает сервер Subversion.

Добавление указания SSLVerifyClient Optional в секции per-server конфигурации Apache (т.е. вне всех блоков VirtualHost и Directory) заставляет Apache запрашивать сертификат клиента при начальном установлении связи с использованием SSL. Из-за ошибки в mod_ssl необходимо, чтобы сертификат запрашивался на этой стадии, поскольку это не сработает при повторном установлении SSL-соединения.

Решением будет добавление следующего указания к папке виртуального узла, к которой желательно ограничить доступ для использования Subversion

SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

Это указание предоставляет доступ к папке только в случае, если сертификат клиента был получен и проверен успешно.

Резюмируя, соответствующие строки конфигурации Apache выглядят следующим образом:

SSLVerifyClient Optional

### Конфигурация ОБЩЕДОСТУПНОГО виртуального узла
### (не запрашивающего сертификат)

<VirtualHost 127.0.0.1:443>
  <Directory "путь_к_общедоступному_файловому_корню">
  </Directory>
</VirtualHost>

### Конфигурация виртуального узла SUBVERSION
### (требующего клиентский сертификат)
<VirtualHost 127.0.0.1:443>
  <Directory "корневой путь узла subversion">
    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
  </Directory>

  <Location /svn>
    DAV svn
    SVNParentPath /путь_к_хранилищу
  </Location>
</VirtualHost>