Основная идея этой статьи — помочь тем, кто решил заморочится с управлением версий, а так же уберечь их от множества граблей, на которые наткнулся я.

Как я к этому пришел.

После очередного неудачного полета раздела, после которого удалось восстановить не всю информацию, ко мне в голову пришла идея хранить свои проекты на удаленном сервере. Данные архивы должны быть легко обовляемы и мобильны, чтобы особо с этим не заморачиваться. Так же, я подумал, что хорошо бы хранить несколько версий, дабы в случае чего, можно было заменить все назад. После недолгого поиска в интернете я наткнулся на CVS и Subversion. Однако так как CVS уже устарело, решил попробовать использовать Subversion. Более подробнее вы можете прочитать по ссылкам, которые я дал выше.

Subversion относится к свободно-распространяему ПО, оно является мультиплатформеной и ее архивы можно прочитать в любой операционной системе. Так же — очень богатые мануалы по настройки (но их очень много и там не всегда есть все, что нужно).

Сервер и клиент

Сервер под Linux является консольным, однако все мануалы на русском и разобраться не так уж и сложно как кажется. На Windows есть VisualSVN (который, кстати, как плагин может цепляться к Visual Studio).

По поводу клиентов — вообще на любой IDE есть либо плагин, либо уже вмонтированый инструмент. Его без труда можно найти в NetBeans, Eclipse, Zend Studio (Платный, однако может кто юзает) и многие другие. Однако, если и нет, то это не беда. Под Linux GUI версии есть всегда, а под Windows однозначно советую попробовать TortoiseSVN. Распространяется свободно, имеет русский язык и мануалы, идет как поднастройка Explorer, работает на ура даже с Windows 7.

Настройка сервера

Большинство статей, которые я находил и интернете, рассказываю о том, как поставить Subversion и Trac. Причем это подразумевает и настройку Apache. Однако, нужно ли эти примочки на сервере, которыми будут пользоваться единицы (ну вдруг я захочу подпустить еще одного человека до разработок). На мой взгляд — это лишнее. Ну начнем по порядку.

Для Windows все просто. Если это VisualSVN, то репозитории создаются довольно просто. Доступ к архивам может быть по следующим протоколам:

    file:/// — прямой доступ к хранилищу (на локальном диске)
    http:// — доступ через протокол WebDAV (если Subversion-сервер работает через Apache, что в моем случае — не желательно)
    https:// — то же, что и http://, но с SSL-шифрованием
    svn:// — доступ через собственный протокол к серверу svnserve (вот это уже ближе к телу)
    svn+ssh:// — то же, что и svn://, но через SSH-соединение (к этому вернемся чуть позже)

Более подробную информацию и основную терминологию вы сможете прочитать в книге «Управление версиями в Subversion».

Рассмотрим настройку сервера именно под Linux. Первое с чего я начал — это попытался настроить доступ к хранилищу по протоколу svn://. За доступо по этому протоколу отвечает приложение svnserve (Собственный отдельный сервер, запускаемый как процесс-демон и доступный посредством SSH; еще один способ для предоставления сетевого доступа к хранилищу), запущенное как демон:

> svnserve -d -R -r /srv/svn/repository/

Обращаю отдельное внимание на ключ -R (мои первые грабли :) ), он установлен при инсталяции по умолчанию. Данный ключ говорит о том, что репозитории доступны только для чтения и как бы вы не настраивали права, записать в репозитории ничего не получится. Для эксперементов можно убрать, однако позже установите обратно.

Создадим первый тестовый репозиторий в папке /srv/svn/repository/:

> cd /srv/svn/repository/
> svnadmin create test_repo
> chown -R svn:svn test_repo

Последняя программа необходима для того, чтобы у пользователя, из под которого работает svn, были права на данную папку. В моем случае это пользователь svn с группой svn.

Если демон svnserve уже запущен, вы можете проверить доступность репозитория:

>svn info svn://localhost/test

Path: test
URL: svn://localhost/test
Repository Root: svn://localhost/test
Repository UUID: 41adfb24-2a9f-11df-9315-49df6e3dca58
Revision: 0
Node Kind: directory
Last Changed Rev: 0
Last Changed Date: 2010-03-08 13:42:13 +0300 (Пнд, 08 Мар 2010)

Если вы получили подобный ответ, то сделали все верно. Теперь настроим его:

> cd test/conf/
>ls -al

drwxr-xr-x 2 svn svn 4096 Мар  8 13:42 .
drwxr-xr-x 6 svn svn 4096 Мар  8 13:42 ..
-rw-r--r-- 1 svn svn 1080 Мар  8 13:42 authz
-rw-r--r-- 1 svn svn  309 Мар  8 13:42 passwd
-rw-r--r-- 1 svn svn 2279 Мар  8 13:42 svnserve.conf

svnserve.conf — основной файл настройки репозитория
passwd — типовой файл пользователей
authz — доступ для пользователей

Основная настройка находится в файле svnserve.conf. Рассмотрим поближе:

[general]
# Правило по умолчанию для анонимных пользователей. По умолчанию - только чтение. 
# Если нужно запретить, разархивируйте и установите none
# anon-access = read 
# Правило по умолчанию для авторизованых пользователей. По умолчанию - чтение и запись.
# Для того, чтобы разграничить права, рекомендую поставить none или read, в зависимости
# от того, что именно вам требуется
# auth-access = write
# Файл, хранящий логины и пароли пользователей к данному архиву
# password-db = passwd
# Файл, который хранит разрешения для пользователей
# authz-db = authz
# Приветсвенное сообщение при авторизации
# realm = My First Repository

В файле passwd пользователи хранятся следующим образом:

login = password
login2 = password

В файле authz хранятся разрешения для пользователей. Пользователей так же можно сгруппировать и назначать уже группы.

Если вы хотите воспользоваться одним из этих файлов, не забудте их расскоментировать в файле svnserve.conf.

Данные пользователеи не имеют к системе ни какого отношения. Это установка пользователей и прав для данного архива. Если архивов несколько, а вы хотите использовать одни и теже файлы прав, достаточно указать их местоположение от корня.

Итак, мы запустили сервер, создали тестовый репозитарий, установили права. Теперь мы можем подключиться к тему по протоколу svn:// с помощью любого удобного нам клиента. Однако, мне показалось это не безопасным. Если вдруг возникнут какие-нибудь проблемы с правами, то даже обычные пользователи могут получить доступ к репозитариям. И я решил добавить дополнительную защиту. Подключатся по протоколу svn+ssh://. Это означает, что сначала пользователь должен авторизоваться в системе, а только после этого получить доступ к архивам.

Для запуска svnserve в терминальном режиме используется ключ -t. Основная схема такая — пользователь авторизуется в системе по сертификату, после чего сразу же запускается svnserve в следующем режиме:

svnserve -t -r /srv/svn/repository/  --tunnel-user=agentsib

Причем --tunnel-user=agentsib устанавливается в зависимости от предьявленого сертификата.

Как это осуществить?

Самое первое, что нужно сделать, это проверить настройки. Следующие опции должны иметь значения:

PubkeyAuthentication yes
PermitEmptyPasswords no

Далее, нам нужен пользователь, под которым мы будем входить. Я выбрал пользователя svn, чтобы не создавать нового.
ВНИМАНИЕ!!! Вход этому пользователю должен быть запрещен!

Далее этому пользователю нужно установить домашнюю директорию.

> usermod -d /srv/svn/repository/ svn

Теперь, так как это уже домашняя папка этого пользователя. создадим там папку .ssh и перейдем туда:

> md .ssh
> cd .ssh/

Создадим ключи для примера:

> ssh-keygen -b 1024 -t dsa -N парольная_фраза -f keys

Парольную фразу, кстати, можно не указывать. Я, например, этого делать не стал. В результате этой операции, у вас создадутся два файла — keys (закрытый ключ) и keys.pub — открытый ключ. Закрытый ключ копируем себе на локальный компьютер, по нему мы и будем авторизовываться, а с открытым делаем следующую манипуляцию:

> mv keys.pub authorized_keys

Если же файл authorized_keys уже существует, то их надо слить

> cat keys.pub >> authorized_keys

Таким образом по закрытому ключу можно авторизоваться и получать доступ к системе. Для того, чтобы в зависимости от ключа у нас запускалось нужное преложение, отредактируем файл authorized_keys следующим образом:
Допустим его содержимое — один публичный ключ:

AAAAB3NzaC1kc3MAAACBAN9T9oXYaK9OT0UlCNvF2n1v0p8hybyim+o+fmW77JQTsOz2alYUzbM6Ze/RxEbnuhIcTk2XGmFJPClMFQqOAI0hrbLXlScsE9nH6KOo/O3qAcaR2lYBNl/MTlkyZGSPmQY4f6iy7N6UQV3FQu7mLMaa2NLTFlfewi/kQwHYRfqBAAAAFQCcIT0OmU0m5uiXvufwZg1iRq0mnwAAAIAi7J5g2A+h1yF4tPHto+doY79oRaCaivJuXKauC1hiLz9s0gOalPjsvGCqM8Ns+ipQBqHTav7a+uh85Vmu2wTksshsoxcgI54B1NSU8PhYa1BelGmTpoWmLhzwAM2yY4CGceE/IsKeMiZi9NjduT7lWuwXyH699yYL3o7ZoDcmsQAAAIEAvZa1hcO6gfowGiNu18RLVaomSHzPJ01q+pCllDbMxOcoCjCoDIxVmnNb8R0Eeu6Pi4R2DTcctSG7CVT1Y4VUYqnFa0n7bbyJj83xQUZ9YduHm9hrkkawaDeMDl3th5HrqpqVYyxeoDM+4W2APy/00W35swxZ/sD/iWgHDVLmsCa= comments

Отредактируем его следующим образом:

command="svnserve -t -r /srv/svn/repository/  --tunnel-user=agentsib",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAN9T9oXYaK9OT0UlCNvF2n1v0p8hybyim+o+fmW77JQTsOz2alYUzbM6Ze/RxEbnuhIcTk2XGmFJPClMFQqOAI0hrbLXlScsE9nH6KOo/O3qAcaR2lYBNlMTlkyZGSPmQY4f6iy7N6UQV3FQu7mLMaa2NLTFlfewikQwHYRfqBAAAAFQCcIT0OmU0m5uiXvufwZg1iRq0mnwAAAIAi7J5g2A+h1yF4tPHto+doY79oRaCaivJuXKauC1hiLz9s0gOalPjsvGCqM8Ns+ipQBqHTav7a+uh85Vmu2wTksshsoxcgI54B1NSU8PhYa1BelGmTpoWmLhzwAM2yY4CGceEIsKeMiZi9NjduT7lWuwXyH699yYL3o7ZoDcmsQAAAIEAvZa1hcO6gfowGiNu18RLVaomSHzPJ01q+pCllDbMxOcoCjCoDIxVmnNb8R0Eeu6Pi4R2DTcctSG7CVT1Y4VUYqnFa0n7bbyJj83xQUZ9YduHm9hrkkawaDeMDl3th5HrqpqVYyxeoDM+4W2APy/00W35swxZ/sD/iWgHDVLmsCa= comments

Это должна быть отдна длинная строка. Если вы добавляете еще одного пользователя, то сгенерируйте еще один сертификат добавьте еще одну строку. Отсюда следует, что если пользователь авторизуется по закрытому ключу, то запустится svnserve, которое присвоет пользователю привелегии agentsib'a.

Преимущества данного подхода таковы, что не требуется хранить в открытом виде, а следовательно файл passwd в конфигурации репозиториев не нужен вообще. Далее — работа svnserve в режиме демона не требуется, так как приложение запускается непосредственно после входа в систему пользователя svn. Ну и передача исходников по зашифрованому каналу — тоже не маловажно.

И так, сервер мы настроили, давайте проверим его. С моего домашнего компа выглядет это так

agentsib@home:~> ssh -2 -i /home/agentsib/keys svn@SERVER
PTY allocation request failed on channel 0
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) )

Если вышла строка вроде ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) ), это означает, что мы все сделали правильно, данная строка — ответ svnserve. /home/agentsib/keys — путь до закрытого ключа уже на моей локальной машине.

Точно такую же проверку можно сделать и через PuTTY. Однако, так как у файла закрытого ключа нет общего стандарта, воспользуйтесь утилитой PuTTYgen, входящий в состав PuTTY для конвертации под него.

Ну в общем то и все. Мы получили сервер Subversion. Далее, для того чтобы подключится, ссылка должна выглядеть так: svn+ssh://svn@SERVER/test_repo/. Сертификат необходимо указать в файле конфигурации Subversion. В линуксе этот файл находится /home/USER/.subversion/config, а в Windows С:\Documents And Settings\USER\Application Data\Subversion\config. В разделе [tunnels] нужно указать следующее:

[tunnels]
# Linux
ssl = ssl -2 -i /home/agentsib/keys -l svn # Так же если есть пароль
# Windows
ssl = plink.exe -2 -i c:/keys -l svn # Так же если есть пароль

Обращаю ваше внимание, что в пути для Windows я указал верные слешы, либо как вариант нужно использовать удвоеные обратные слешы. Приложение Plink входит в состав PuTTY, однако можно указать путь к модифицированому Plink, который входи в состав TortoiseSVN. Основное отличие в том, что вы не увидете консольных окон.

Для TortoiseSVN есть возможность настроить подключение через PuTTY. Вы создаете подключение к серверу, указываете ключи и называете соединение скажем TEST. После чего в программе TortoiseSVN путь к репозиторию будет выглядеть так svn+ssh://svn@TEST/test_repo. Более проднобно о настройке самой программы вы сможете прочитать в ее мануалах. Или по адресу http://tortoisesvn.net/docs/nightly/TortoiseSVN_ru/tsvn-ssh-howto.html.

Если появятся вопросы — пишите сюда, обязательно отвечу.

Удачного коннекта)