- Подписка на печатную версию:
- Подписка на электронную версию:
- Подшивки старых номеров журнала (печатные версии)
LXF118:Subversion
Материал из Linuxformat.
- Сети Свяжем ваши Linux-ПК, и пускай они вас обслуживают
Содержание |
Subversion: Сотрудничаем
- Часть 5: Нужна совместная работа над файлами? Нейл Ботвик покажет, как Subversion поддерживает актуальность вашей информации, не наступая никому на пятки.
Нет, ничего общего с государственным переворотом тут нет. Кстати, если вы его задумали, то Subversion [англ. «свержение»] – наименее подходящая программа для подобных целей. Как честный инструмент для совместной работы над проектами, она регистрирует каждое дополнение, изменение и удаление, а также кто и когда его произвёл, тем самым сводя к нулю все шансы на подпольную деятельность. Итак, что же такое Subversion? Это одна из систем контроля версий (version control software, VCS), используемая для отслеживания и записи всех изменений в наборе файлов. Чаще всего она употребляется (особенно в мире открытого ПО) для управления программными проектами, но её с успехом можно применить при работе с любым набором файлов: web-сайт, документация или коллекция видео или аудио – содержимое роли не играет. Благодаря этому сервер Subversion пригодится для многих видов проектов, и на следующих страницах мы расскажем, как начать с ним работу.
Контроль чего?
Основная задача любой системы контроля версий, как следует из названия – это управление различными версиями проекта. При каждом внесении изменений в файл и регистрации их на сервере, Subversion сохраняет их в виде новой версии проекта, давая вам или кому-то другому возможность увидеть данные в их текущем или более раннем состоянии. Если что-то работает не так, как предполагалось, можно просто откатиться к последней рабочей версии и попробовать другой подход.
Другое ценное преимущество – то, что над проектом может работать множество разных людей. Каждое изменение снабжается именем автора, и сразу видно, кто что внёс. Любой может забрать набор файлов, переделать их и отослать обратно. Тогда новые файлы станут доступны всем пользователям. А вдруг два пользователя возьмутся за один и тот же набор файлов? Первоначальным решением было такое: после того, как некий пользователь извлёк файлы из репозитория, блокировать их, запретив к ним доступ вплоть до фиксации изменений. Но такой подход часто неэффективен, поэтому Subversion и другие инструменты контроля версий теперь по умолчанию используют другой способ:
- Пользователь А извлекает файлы из репозитория и принимается с ними работать.
- Пользователь Б делает извлечение из того же каталога и получает ту же начальную копию, поскольку пользователь А ещё не зафиксировал никаких изменений.
- Пользователь А делает изменения в паре файлов и фиксирует их.
- Пользователь Б вносит какие-то изменения и пытается их зафиксировать.
Тут программа-клиент Subversion видит, что с тех пор, как пользователь Б извлёк из репозитория свой набор файлов, в нём произошли изменения, и обновляет их. Если обновление касается разных файлов, то проблем нет, и можно фиксировать дальше. Если же оба пользователя меняли один и тот же файл, Subversion проверит, совместимы ли изменения. Если изменения касаются разных частей файла, оба набора сливаются, и фиксация продолжается. В противном случае пользователь Б информируется о конфликте, и ему предлагается разрешить проблему вручную.
Звучит сложно, но в большинстве случаев такая схема работает хорошо. Лишь в одной ситуации слияние различных правок в одну не срабатывает: когда искомый файл – не текстовый. С последними всё просто, поскольку они состоят из отдельных строк или, если работа идёт с документацией, абзацев. Но для файлов, содержащих двоичные данные, как, например, мультимедиа-ролики, этот под ход уже не годится, и тогда блокировка файла вплоть до внесения сделанных изменений – лучшее решение.
Установка сервера
Пакет с Subversion должен быть в репозиториях вашего дистрибутива, так что установите его обычным способом. Как правило, сервер и штатный клиент идут вместе, хотя существуют и другие способы доступа к репозиторию Subversion, о которых мы поговорим чуть ниже. После установки можно выбрать один из двух режимов работы сервера svnserve. Самый простой – запустить его как самостоятельный демон: отметьте в программе настройки служб вашего дистрибутива, чтобы демон запускался при загрузке системы. Если вам незачем постоянно держать сервер запущенным, стартуйте его из inetd или xinetd. Для дистрибутива, где используется классический супер-демон inetd, допишите в файл /etc/initd.conf следующее:
svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i
У пользователей xinetd, возможно, уже имеется файл svnserve в каталоге /etc/xinetd.d. Тогда просто поменяйте значение параметра “disable” на no; в противном случае создайте файл следующего содержания:
service svn
{
socket_type = stream
wait = no
user = apache
group = apache
umask = 002
protocol = tcp
log_on_failure += USERID HOST
port = 3690
server = /usr/bin/svnserve
server_args = -i
disable = no
}
Перезапустите inetd или xinetd или отправьте им сигнал SIGHUP, чтобы изменения вступили в силу.
Настроим ваш первый проект
При публикации изменений всегда добавляйте какой-нибудь осмысленный комментарий. Поначалу это может показаться занудным, но впоследствии вы себя возненавидите, если не будете этого делать.
Первый шаг после установки – создание репозитория. С одним-единственным проектом это не вопрос, но при наличии нескольких проектов встаёт выбор: иметь несколько репозиториев или использовать несколько каталогов внутри одного. Второе проще и рекомендуется в большинстве случаев, так что мы опишем именно этот способ. Зайдя на сервер с правами root, наберите:
svnadmin create /var/svn/repos
Это местоположение по умолчанию, но можно указать любой путь. Будет сгенерирована базовая файловая структура; теперь нужно создать в ней директории для проектов. Стандартная практика – иметь в каждом каталоге проекта три подкаталога: trunk, branches и tags, причём все рабочие файлы хранятся в trunk. Поначалу такие сложности могут и не понадобиться, но в дальнейшем вы порадуетесь, что настроили всё по такому принципу. Вот типичная раскладка:
/var/svn/repos
project1
branches
tags
trunk
project2
branches
tags
trunk
Репозиторий Subversion – это база данных, представленная как виртуальная файловая система, поэтому просто взять и создать такую раскладку в виде подкаталогов в repos не удастся. Для манипулирования файлами и каталогами предусмотрен собственный инструментарий Subversion. Дерево проекта создаётся так:
svn mkdir --parents file:///var/svn/repos/project1/{trunk,tags,branches}
Далее можно импортировать существующее дерево исходных текстов куда-то в репозиторий. Представьте, что мы работаем над web-сайтом в /var/www/localhost/htdocs; перенести его в Subversion можно так:
svn import /var/www/localhost/htdocs file:///var/svn/repos/website/trunk -m “Initial import”
Флаг -m сообщает, что к журналу добавляется комментарий; если вы не укажете текст в командной строке, вам предложат его ввести. Вы убедитесь в полезности этих действий потом, отыскивая более старые версии! Теперь ваш web-сайт попал в репозиторий Subversion, но /var/www/localhost/htdocs не является рабочей копией – её нужно извлечь в тот же каталог таким образом:
svn checkout file:///var/svn/repos/website/trunk/var/www/localhost/htdocs
или
cd /var/www/localhost/htdocs svn checkout file:///var/svn/repos/website/trunk .
Точка (.), означающая текущую директорию, очень важна. Если не указать места назначения, рабочая копия выберет себе название по последней составной части имени проекта, и вы получите каталог trunk – то есть совсем не то, что хотели.
Просмотр содержимого директории покажет, что оно осталось прежним, только добавился каталог .svn, где содержится информация, нужная для Subversion – не удаляйте его. Теперь можно вносить изменения и публиковать их на сервере командой
svn commit
Перед фиксацией изменений, возможно, вам захочется выполнить
svn status
что покажет список модифицированных файлов. Текущие изменения в файле можно просмотреть по команде svn diff, она работает аналогично стандартной diff.
Работа с Subversion
Клиент svn – главная рабочая лошадка Subversion. Эта программа работает непосредственно с репозиторием. В предыдущих примерах мы задавали пути до репозитория нашего проекта в виде file:///URI. При настройке это удобно, но коллективную работу немного ограничивает. Для прямого соединения с сервером svnserve так же можно использовать svn:// URI, так что эти две команды эквива лентны:
svn checkout file:///var/svn/repos/website/trunk . svn checkout svn:///localhost/repos/website/trunk .
Заметьте, что здесь указаны не полные пути, а только пути относительно корневого каталога Subversion, и, как правило, это /var/svn. Конечно же, URI не обязательно должен быть локальным: можно разрешить соединение с другого компьютера в вашей сети, или откуда-то ещё из Интернета, приняв обычные в таких случаях меры безопасности.
Настроив рабочую копию, примите во внимание пару вещей. Во-первых, новый файл, созданный в рабочей копии, не добавляется к репозиторию Subversion при следующей фиксации изменений сам по себе. Это необходимо потребовать явно, командой
svn add PATH
где PATH может быть файлом, каталогом или шаблоном имени. Не будет беды, если добавится файл, который уже есть в репозитории, так что
svn add *
– вполне разумный способ включить сразу всё, что нужно. То же касается удаления, копирования и переименования файлов. Вместо команд rm, cp и mv пользуйтесь svn rm, svn cp и svn mv, которые удалят, скопируют или переименуют файл и опубликуют изменения на сервере при следующей фиксации. Также, вместо
mkdir somedir svn add somedir
можно применить svn mkdir.
В Subversion есть встроенная онлайн-справка. Для получения списка команд введите
svn help
а для получения дополнительной информации о конкретной команде –
svn help command
Полная информация доступна в Subversion Complete Reference [Управление версиями в Subversion], на DVD или на сайте http://svnbook.red-bean.com.
Безопасность и контроль доступа
Не бойтесь экспериментировать: ведь в Subversion ничто не теряется! Все ваши ошибки и все удачные решения пребудут на сервере вечно.
Тут действуют общепринятые правила по предоставлению доступа из Интернета. Главное из них – не делать того, в чём нет нужды. Если необходим доступ извне, анонимным пользователям в лучшем случае предоставьте права только на чтение. При работе над открытым проектом можно предоставить возможность извлечения файлов глобально, но права на запись должны быть только у зарегистрированных разработчиков. Впрочем, Subversion (как и любая система контроля версий) имеет огромный плюс: тут ничего не теряется. Если кто-то, заполучив права на запись, злостно изменит или поудаляет файлы, старые копии все равно останутся на месте, и вы просто откатитесь к ревизии, созданной до нашествия вандалов.
Вам вряд ли нужно, чтобы кто ни попадя из Интернета мог извлекать ваши файлы и тем более фиксировать в них изменения; а как организовать защиту? Первым шагом будет, как и всегда, настройка брандмауэра. Решив дать доступ к файлам только локальным пользователям, заблокируйте внешний доступ к соответствующим портам. Под стандартный интерфейс HTTP/WebDAV отведён порт 80, а для использования svnserve – 3690. При работе через HTTP весь доступ контролируется web-сервером способами, описанными в учебнике про Apache в начале нашей серии статей (LXF113/114). У svnserve есть собственная система аутентификации, настраиваемая в подкаталоге conf/svnserve.conf главной директории repos. Параметры по умолчанию таковы:
anon-access = read auth-access = write
То есть извлекать файлы могут все, но фиксировать изменения вправе только зарегистрированные пользователи. Естественно, вы можете изменить настройки согласно вашим нуждам. Для любой из них можно указать параметр ‘none’: так,
anon-access = none auth-access = write
позволит изменять файлы только авторизованным пользователям, а
anon-access = read auth-access = none
создаст публичный репозиторий, доступный исключительно для чтения. Также можно указать файл, используемый при авторизации:
password-db = passwd
Путь задаётся относительно svnserve.conf. Формат этого файла – по строке на каждого пользователя:
[users] user1 = password1 user2 = password2
Как говорилось выше, Subversion не знает понятия «проекты»: здесь это просто каталоги в репозитории. А если надо контролировать доступ к конкретным проектам (другими словами, к каталогам)? Это делается с помощью файла authz из каталога conf. Раскомментируйте указания на него в svnserve.conf и настройте доступ в самом файле authz таким способом:
[/myproject] user1 = rw user2 = r * =
Мы установили контроль над доступом к каталогу myproject и всем его подкаталогам. Пользователь user1 имеет права на чтение/запись, user2 может только читать, а другие не имеют никаких прав доступа вообще. Когда authz-db вступит в силу, доступ закроется всем, кроме специально оговоренных лиц; не исключено, что придётся добавить
[/] * = r
разрешив чтение остальным пользователям. Не перестарайтесь, урезая права доступа для коллективного проекта. Лучше доверить право на изменение файлов пользователям с должной квалификацией, чем ограничивать им доступ.
Машина времени
Сервер Subversion подобен машине времени – ничто никуда не исчезает. Удаляя файл из рабочей копии и затем фиксируя изменения на сервере, мы удаляем файл только из новой ревизии. После правки файла и публикации изменений старая версия по-прежнему находится в предыдущей ревизии. Пока мы работали только с самой свежей версией (выбираемой по умолчанию, когда мы извлекаем рабочую копию), но можно откатиться к любой на ваш вкус. Для начала узнайте, какие ревизии доступны. Команда
svn log
покажет ревизии текущей копии в обратном порядке, включая время, комментарий и имя пользователя, зафиксировавшего изменение. Сузить список отображаемых ревизий можно одним из следующих способов:
svn log -r 25 svn log -r 25:15 svn log -r 15:25
Первый покажет одну ревизию, второй – указанный диапазон ревизий, а третий сделает то же самое, но в прямом хронологическом порядке. Добавление флага -v выведет список изменённых файлов. Также можно указать путь или URI: команда
svn log -v svn://hostname/repos
выведет все изменения, сделанные в данном репозитории, не прибегая к извлечению файлов. Обнаружив версию, с которой вам хотелось бы поработать, извлеките её или же обновите имеющуюся рабочую копию, добавив -r number к соответствующей команде svn. Опубликовать такую копию нельзя, поскольку уже существуют более поздние фиксации, но можно с ней поработать, чтобы убедиться, что вам именно это и нужно. Если вы захотите добавить более старые, удалённые или изменённые файлы снова в текущую рабочую копию, это делается с помощью svn copy:
svn copy svn://hostname/repos/project/trunk/somefile@NNN ./somefile
где NNN – номер ревизии. Данный синтаксис можно использовать для доступа к файлам любой версии. Теперь, когда файлы снова находятся в рабочей копии, следующая публикация изменений добавит их в проект.
Графические возможности
До сего момента всё делалось с помощью консольного клиента svn. Это полезно для обучения работе с Subversion, поскольку помогает лучше ухватить суть происходящего; но для общего использования вполне можно предпочесть графический подход. Существует несколько специализированных графических клиентов, включая RapidSVN (созданный там же, где и Subversion), и мы включили их подборку на наш DVD. У пользователей KDE есть выбор из пары кандидатур: полноценного клиента kdesvn и Konqueror для просмотра репозиториев через адреса типа svn://URI. Разместив свой код в Subversion, вы сможете получить к нему доступ и из популярных IDE: большинство интегрированных сред предлагают поддержку Subversion, встроенную или в виде подключаемого модуля.
На этих четырёх страницах мы коснулись только самых вершков возможностей Subversion. Справочное руководство содержит более 400 страниц, ведущих от базовых навыков к сложным настройкам. С его помощью вы найдёте ответы на любые вопросы, возникшие у вас во время чтения нашей статьи, так что обязательно просмотрите экземпляр руководства на нашем DVD. LXF
Словарьглоссарий
Прежде чем продолжить установку и настройку Subversion, опишем терминологию, применяемую в системах контроля версий.
- Репозиторий (хранилище) Полный набор файлов, управляемых системой контроля версий.
- Проект Подмножество репозитория. Представ ляется в виде подкаталога, хотя в Subversion, по сути, нет понятия проекта как такового – оно применяется только для удобства простых смертных.
- Извлечение (Check out) Действие по загрузе рабочей копии из репозитория для работы с ней.
- Публикация изменений (фиксация, Commit) Выгрузка ваших изменений в репозиторий. Subversion знает, какие файлы вы отредактировали, и отсылает в репозиторий только модифицированные данные. Именно на этом этапе Subversion проверяет, не зафиксировал ли кто-нибудь ещё изменений для файлов, которые изменяли и вы. Фиксация изменений в Subversion атомарна, то есть, изменив несколько файлов, вы обновляете либо их все, либо ни одного, даже при аварийном завершении программы или обрыве связи во время фиксации изменений.
- Рабочая копия Набор файлов, которые вы правите; локальная копия части репозитория. Когда ваши правки вас удовлетворят, вы посылаете их обратно в репозиторий. Рабочая копия так же содержит каталог .svn – но он не является частью проекта.
- Обновление (Update) Обновление вашей рабочей копии пу тём загрузки любых, кем-то когда-то сделанных изменений.
- Версия (Revision, «ревизия») При каждой фиксации пользователем изменений для одного или более файлов номер версии увеличивается. В отличие от других систем кон троля версий, в Subversion применяется глобальный номер ревизии, а не отдельная ну мерация для каждого набора файлов.
- Головная версия (Head) Самая свежая ревизия – именно её вам предоставят при извлечении файлов с сервера или обновлении локального проекта.
Subversion по HTTP
На нашем уроке мы использова ли сервер svnserve и адреса типа svn://URIs: это наиболее простой подход. Но репозиторием так же можно управлять по HTTP, с помощью сервера WebDav. Руководствуясь инструкциями из первой части этой серии статей, вы должны бы уже настроить себе Apache, а теперь добавьте к его конфигурации следующее:
LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so <Location /svn> DAV svn SVNParentPath /var/svn </Location>
Теперь вы можете соединиться с http://hostname/svn/repos. Не исключено, что аналогичный набор директив уже присутствует в /etc/apache/modules.d, и тогда вам остается лишь аккуратно настроить пути. Это базовый шаблон; при желании добавьте установки для аутентификации пользователей, ограничив доступ.
