Запись была отнесена к рубрике «Техники» 15.02.2008, Пт в 08:26. Вы можете следить за общением по теме этой записи с помощью RSS 2.0 ленты. Вы можете оставить отзыв, или trackback с Вашего сайта.
- RSS
- SVN
- HTML
Введение в Subversion
Системы контроля версий. Согласитесь, звучит. А чем дольше пользоваться одной из них, тем все более соблазнительные для искушенных умов рисуются перспективы. Начнем.
В этой статье мы поговорим, установим и попытаемся использовать в своих корыстных целях одну из разновидностей СКВ — Subversion. Почему так? Subversion очень популярна среди разработчиков, предоставляется многими хостерами, а возможная тесная интеграция с web-сервером Apache только добавляет ей очков. Чем-то Subversion походит в этом отношении на PHP — также много отличных альтернатив, но…
на заметку
Примечание: не стоит думать, что Subversion это «только под web и для web». Соответствующим образом настроенная эта СКВ подойдет всем кто к ней готов.
Причины использования
Подавляющее большинство разработчиков приходят к СКВ, когда им перестает хватать резервного копирования проекта в виде стека директорий (оставим в стороне случай, когда использование СКВ — требование «свыше», мы все не любим насилие). Кто-то пытается подвести под наименование таких директорий некую систему (к примеру, в виде дат), кто-то хранит описание копий в файлах, кто-то находит решение в соответствующем ПО вроде nnbackup. Однако приходит определенный момент и мысли тянутся к более эффективным решениям — СКВ. Установив одну из них, можно не беспокоиться о создании резервных копий данных — все будет сделано автоматически. Более того, вскоре вы даже забудете о таком явлении как резервирование, вы будете пользоваться широкими возможностями СКВ, не замечая, что создается один backup за другим. И это хорошо.
Также одной из самых распространенных причин применения СКВ может служить командная разработка. В таком случае контроль монопольного редактирования, отслеживание изменений и их слияние являются настоящим кошмаром, если не использовать СКВ.
малый итог
Использование СКВ оправдано как в случае одиночного разработчика, так и для ситуации когда их несколько.
Общая теория
Для начала необходимо усвоить базовые понятия и термины, единые для большинства различных СКВ. Их не много:
- repository (хранилище) — место где СКВ хранит данные, информацию об их изменениях и другую системную информацию;
- checkout — извлечение части или всего содержимого хранилища и создание на их основе рабочей копии;
- working copy (рабочая копия) — слепок хранилища расположенный на локальной машине. Именно рабочая копия подвергается изменениям перед тем как данные будут занесены в хранилище. Рабочая копия содержит также данные о версиях содержащихся в ней файлов. Именно их наличие и определяет, что директория и есть рабочая копия;
- revision (версия, номер правки, правка) — каждый объект в понятиях СКВ имеет версию, номер которой назначается автоматически, если документ изменялся;
- commit (закрепление изменений) — копирование изменений из рабочей копии в хранилище. При этом создается новая правка;
- update (обновление) — операция получения данных из хранилища, если в рабочей копии они устарели;
- merge (слияние) — объединение независимых изменений над одним файлом. Такое происходит, когда в разных правках менялся один и тот же файл.
Также потребуется рассмотреть самые известные реализации СКВ, чтобы знать об их возможностях и недостатках:
- CVS (Concurrent Version System) — система, своими корнями уходящая в далекие 80-е, очень популярна и сейчас. Обладает почти всеми необходимыми инструментами для контроля изменений, сравнения, слияния и устранения конфликтов. Существенным минусом данной реализации является отсутствие контроля версий директорий;
- VSS (MS Visual SourceSafe) — реализация СКВ софтверного гиганта, ориентированная на индивидуальных разработчиков или небольшие их группы. Доступна посредством установки Visual Studio. Имеет старшего брата Visual Studio Team Foundation Server. К недостаткам относится Win32-ориентация;
- SVN (Subversion) — система контроля версий пришедшая на смену CVS и призванная устранить все ее недостатки. Имеет возможность интегрирования с web-сервером Apache, отслеживает версии не только файлов, но и директорий. За каждым объектом в хранилище можно закрепить любую информацию в так называемых свойствах и она также попадет под контроль версий.
Дополнительную информацию о приведенных и других реализациях СКВ можно найти, запросив Google.
малый итог
Даже на первый взгляд видна исключительная аппетитность SVN. Возможно, дело в предвзятом изложении материала, но вероятнее всего, что это законное положение лидера.
Subversion
Будем последовательны — разовьем тему SVN.
Главное преимущество SVN — интеграция с Apache. Это настоящий подарок web-разработчикам — один привычный сервер, известные подходы в обеспечении безопасности, авторизованного доступа и прочего.
замечание
CVS также имеет модуль позволяющий использовать ее с Apache, но он слабо распространен и последний раз обновлялся в далеком 2003 году.
Свобода на пространстве файловых операций: файлы и директории как в рабочей копии, так и в хранилище можно свободно копировать, перемещать, удалять — никаких накладок это не вызовет.
SVN всегда передает в хранилище «дельту» — только измененные данные. Не важно, бинарный ли это файл или любимые цитаты с башорга, но на сервер отправятся только новые данные.
Спокойствие за свои изменения при закреплении их в хранилище — SVN или закрепит все изменения, или не сделает этого вовсе, так что путаницы не будет.
риторика
Надо ли говорить, что SVN также наследует все положительные стороны своего родителя — CVS.
Отличным инструментом, предоставляемым SVN, является команда вычисления разницы, которая может применяться как к отдельным файлам, так и к правкам. Хотите узнать, что было изменено коллегой или левой рукой за вчерашний день? Это просто.
примечание
Нельзя вычислить отобразить разницу между двумя директориями, двумя фильмами или другими бинарными файлами. К слову, для некоторых бинарных файлов возможность сравнения все же имеется, но реализована она на уровне хака, надстройки. К файлам такого рода относятся в основном файлы офисного пакета MS Office и ограниченный набор файлов изображений.
Несколько разработчиков могут редактировать один и тот же файл и если их изменения не пересекаются, то SVN даже не пикнет — оба изменения будут закреплены автоматически. Возможно, что вы об этом даже не узнаете.
Всегда в распоряжении возможность создания веток — самостоятельных линий разработки, начинающихся в точке ветвления и ничем не отличающихся от основной по принципам работы. Это очень удобно, когда требуется внедрить в проект некую функциональность, реализация которой потребует множества правок. Ваши действия будут мешать остальным разработчикам (или вам самим) просто тем, что какое-то продолжительное время не смогут быть завершены. По окончанию работы в ветке изменения, внесенные в проект на ее пути, можно «слить» в основную линию разработки с минимальными усилиями со стороны разработчиков.
Виды установки
Различают три способа установки SVN сказывающиеся на типе доступа к хранилищу:
- Под управлением web-сервера Apache посредством mod_dav_svn;
- В виде самостоятельного сервиса svnserve — небольшого демона, который для связи с клиентами использует собственный протокол;
- Не устанавливать SVN вовсе.
важно
В случае интеграции с Apache возможна установка только для Apache версии 2.x. Это связано с рядом архитектурных особенностей второй ветки сервера. Если вы используете Apache версии 1.x, можно порекомендовать установить Apache версии 2.x в виде второго web-сервера на другом порту.
Сравнение двух первых способов можно видеть в таблице ниже:
| Возможность | Apache + mod_dav_svn | svnserve |
|---|---|---|
| Авторизация: | стандартное установление личности средствами HTTP (S), сертификаты X.509, LDAP, NTLM, а также другие механизмы, доступные для использования в Apache | CRAM-MD5 или SSH |
| Хранение учетных записей: | внутренний файл «users» | внутренний файл «users» или использование существующих системных (SSH) учетных записей |
| Шифрование: | опционально через SSL | опционально через SSH-туннель |
| Логирование: | полное логирование каждого HTTP запроса как это настроено в Apache | не поддерживается |
| Просмотр через web: | ограниченная встроенная поддержка, или использование программ сторонних разработчиков, таких, как ViewVS | только при помощи программ сторонних разработчиков, таких, как ViewVS |
| Скорость: | более низкая | более высокая |
| Установка: | более сложная | менее сложная |
Оба вышеописанных варианта подразумевают, что доступ к хранилищам будет предоставляться на основе парадигмы «клиент-сервер». Это частая ситуация когда разработчиков много. Однако нередко нужно развернуть систему контроля версий без подобных сложностей. В таком случае потребуется только клиент — программа необходимая в любом случае. У подхода есть один минус — файловая система, на которой находится хранилище, должна быть локальной.
краткий итог
Если заниматься разработкой web-приложений под управлением Apache, то выбор очевиден — один и привычный сервер. В ином случае целесообразно использовать поставляемое с SVN svnserve. Когда же требуется локальная реализация SVN, без доступа извне, то можно обратить внимание на третий вариант.
Настройка
Так как статья носит web-ориентированный характер, мы коснемся только реализации «SVN через протокол WebDAV» под управлением сервера Apache. Этот способ даст нам следующие преимущества по сравнению с другими:
- Просмотр содержимого последней правки хранилища в браузере — мы все любим ссылки;
- Передаваемые данные могут быть сжаты обычным образом с помощью mod_deflate;
- С помощью скриптов на своем любимом языке можно оперировать данными хранилища.
Условимся использовать в этой статье пути, которые используются мной в повседневности: мне удобно излагать, а вам не привыкать видеть чужие конфиги. Также «сразу» предупреждаю, что разговор будет идти на языке Windows. Извините.
Пусть Apache установлен у нас как это видно на рисунке ниже. Содержимое home — ряд директорий, внутри которых имеется директория www — DocumentRoot соответствующего виртуального хоста.
Вид директорий с которыми мы будем иметь дело
вы заметили?
Файловая организация популярного пакета denwer и используемая в данной статье, пересекаются в home — функции этой директории идентичны и там, и там. Этот факт может помочь для перенесения изложенного материала на рабочее пространство denwer.
Убедимся, что у нас есть, установлено и настроено все необходимое:
- Web-сервер Apache;
- Модуль расширения mod_dav.so;
Брать дистрибутив SVN из-за ОСзависимости лучше с сайта разработчика. Установка не вызывает обычно вопросов, но есть пара нюансов:
- Снимите чекбокс конфигурации модулей с перезапуском Apache — мы все сделаем самостоятельно;
- Не поддавайтесь на уговоры установщика и не редактируйте autoexec.bat. Найти смысл в этой рекомендации также сложно, как и сам файл.
Ссылку на дистрибутив TortoiseSVN, визуального клиента SVN для Windows, можно найти во все том же разделе загрузок. Установка. Игнорирование предложения перезагрузиться.
Конфигурирование Apache. Многие используют комплект denwer, у меня своя сборка триады Apache, PHP, MySQL, есть иные варианты. Объединяет их одно — во всех случаях файл httpd.conf должен существовать. Им и займемся:
- Там где у вас скопление директив загрузки модулей «LoadModule» добавьте еще одну:
LoadModule dav_svn_module "@SubversionDir@/Subversion/bin/mod_dav_svn.so"
- Убедитесь, что также активна директива загрузки модуля WebDAV, модуль существует, а его загрузка идет до загрузки dav_svn_module:
LoadModule dav_module modules/mod_dav.so
- Там где вам это кажется уместным, но обязательно в файле httpd.conf создайте описание «директории» для SVN:
<Location /svn> DAV svn SVNParentPath "d:/www/svn_repository" </Location>
Создаем d:\www\svn_repository, перезагружаемся и пытаемся запустить Apache. В случае удачи ничто вас не побеспокоит. Если же что-то пошло не так, то следует разобраться в ошибке с помощью чтения логов и действий по обстоятельствам.
Использование
Теперь, когда все необходимое установлено и работает можно вручить свой проект в надежные руки SVN.
Обычный процесс работы с SVN можно изобразить, как это сделано на схеме ниже, которая отражает полный цикл жизни: от создания хранилища до его использования.
Схема действий при работе с SVN
Примечание
Кружочек с вложенным кружочком на схеме означает, что действие составное — может состоять из многих различных действий.
Разберемся со всем по порядку:
- Создание хранилища;
- предимпортная настройка;
- импорт проекта в хранилище;
- создание рабочей копии;
- редактирование рабочей копии;
- закрепление изменений (правки);
- выборка данных из хранилища;
- отмена изменений.
Для того чтобы различные действия были понятны договоримся каждый из шагов снабжать популярным объяснением которое будет основано на двух персонажах:
- Разработчик — человек, который выполняет работу. К такой работе сводится создание, удаление, изменение файлов составляющих некий продукт или гордость за все вместе взятое;
- Лидер — человек, который определяет линию разработки, а также обеспечивает наличие всех необходимых в разработке вещей, например, данных.
Подобная, очень упрощенная, организация процесса труда принята для повышения эффективности разработки в целом. Но представьте себе ситуацию, когда разработчик, например в ситуации с личным блогом, один. Никто не возьмет на себя роль лидера, ее придется выполнять самостоятельно. Поэтому, если какие-то действия покажутся вам странными и непонятными, попытайтесь распределить роли и все встанет на свои места.
- Создание хранилища. Хранилище или иначе репозиторий — особое место, где SVN в собственном формате хранит все наши данные в виде правок. Директорией, где мы решили разместить хранилища, будет d:\www\svn_repository, а хранилище будет называться web-dev. Тогда создаем директорию d:\www\svn_repository\web-dev и через контекстное меню для нее выбираем TortoiseSVN→Create repository here… Тип репозитория должен быть FSFS. Хранилище создано и готово к работе;
метафора
Этот шаг можно сравнивать с примерным лидером который готовит рабочее место для разработчика наряду с созданием ftp аккаунтов и прочих подобных вещей.
- Предимпортная настройка. Этот шаг опционален и не является каноническим, однако я бы порекомендовал делать его всегда, когда его есть к чему применить. Речь пойдет о настройке рабочей копии в плане задания свойства игнорирования файлов, для которых не нужно хранить информацию о версии (версионировать). Примером таких файлов могут быть «скомпилированные» шаблоны Smarty, файлы проекта редактора PhpED, дампы баз и прочее, что по каким-то причинам расположено в рамках рабочей копии, но не нуждается в отслеживании изменений. Создайте простую копию проекта, а в оригинале удалите все то, что не считаете нужным отдать под версионирование. Пока это все;
метафора
Лидер уже располагает какими-то данными, но он также понимает, что не все из них нужно отдавать в хранилище даже если эти «излишки» нужны в работе. Своими действиями он готовит чистую заготовку рабочей копии без всякого мусора — базовую редакцию.
- Импорт проекта в хранилище. Здесь необходимо сообщить хранилищу базовую редакцию проекта на основе которой он будет, подобно пирамиде из правок (часто очень причудливой — подумайте о ветвлении), хранить наши изменения. Пусть это будет проект блога в котором размещена эта статья: d:\www\ApachePhpMysql\apache\home\web-dev.info\. Импорт осуществляется посредством пункта контекстного меню TortoiseSVN→Import… В качестве запрошенного URL к хранилищу укажите http://127.0.0.1/svn/web-dev/trunk.
для ясности
Частичка svn в этом пути взялась из httpd.conf, где мы указали ее в директиве Location, с тем же успехом можно было бы написать в обоих местах my_pretty_good_svn_directory. Что касается частички trunk, то по ее поводу забегите немного вперед, если вам интересно.
В зависимости от объема импортируемых данных зрелище будет более или менее впечатляющее… и длительное;
метафора
Лидер создает фундамент на котором силами разработчика будет строиться вся разработка. Таковым фундаментом является первая правка в хранилище — результат прошедшего импорта.
- Создание рабочей копии. Теперь самое время… удалить оригинал вашего проекта.
Внимание!
До тех пор пока не будете уверенно использовать SVN, всегда делайте резервирование данных проекта привычным для вас образом. В процессе обучения, чтобы начать все с чистого листа, обычно не раз удаляется хранилище — а значит и резервные копии.
Делается это потому, что оригинал проекта не содержит еще данных о версиях файлов, а значит, не является рабочей копией. Директорию нужно таковой сделать. Для этого и производится удаление, чтобы потом создать под этим же именем директорию, которая будет рабочей копией с точки зрения SVN и файлами, составляющими блог, с точки зрения Apache. Далее, для пустой директории web-dev.info запустите команду контекстного меню SVN→Checkout…, URL хранилища нужно взять из предыдущего шага: http://127.0.0.1/svn/web-dev/trunk. Теперь, после завершения, у вас есть рабочая копия вашего хранилища, с которой можно производить любые действия, вплоть до забрасывания проекта;
метафора
Лидер продолжает заботиться о разработчике и делать свою работу. На этом этапе он создал собственную рабочую копию т.к. необходимо навести порядок с файлами, исключенными на этапе предимпортной настройки. Тем, что над лидером нет никого, кто сделал бы эту работу для него и обусловлена эта чехарда с удалением оригинала и созданием пустой директории.
- Редактирование рабочей копии.
Тут можно дать волю фантазии, например, отбросить ее в сторону и заняться делом. Под редактированием понимается любое изменение содержимого файлов, их переименование, изменение свойств и прочее. Все эти телодвижения скажутся на рабочей копии так, что нам надо будет их сохранить, а в терминах SVN — закрепить. Давайте потратим нашу первую правку на что-нибудь полезное: второй этап настройки списка игнорируемых объектов. Мысленно вернитесь к этапу предимпортной настройки. По его результатам у нас имеется оригинал, ставший после последующих шагов рабочей копией и старая резервная копия. Скопируйте резервную копию поверх рабочей копии. выполните для последней команду TortoiseSVN→Check for modifications и вы увидите все файлы, которые решили не версионировать с пометкой «non-versioned». Можно отметить их как игнорируемые, в чем клиент предоставляет нам довольно большую свободу посредством контекстного меню, вызываемом при клике правой кнопкой мыши на не версионированных объектах. Дело за вами и пусть эти изменения будут пока единственными;метафора
Лидер и разработчик на данном шаге одноправны — оба вносят различного рода изменения. То, что мы лишь добавили игнорирование некоторых объектов, не говорит, что это единственное действие, которое можно производить для изменения хранилища. Например, разработчик всегда будет менять файлы, находясь на этом этапе, самом часто посещаемом.
- Закрепление изменений. Действие сводится к выбору команды контекстного меню SVN Commit… Причем для какого объекта вы ее выбрали, тот и будет закреплен. Это открывает большие возможности по ветвлению в рамках одной ветки: можно разбить ряд внесенных изменений по правкам. Commit для всей рабочей копии, естественно приведет к закреплению всех изменений, что вы и сделали в конце предыдущего шага. Вообще, закрепление изменений рекомендуется делать осмысленно. Не раз в день, не каждые 3.14 минуты, а по задаче. В качестве примера, локализация плагина WordPress — отличная вещь, умещающаяся в одной правке. А вот локализацию большего их числа лучше разбить на несколько. Идея проверить что-либо «на живую» тоже вполне втиснется в рамки одной правки. Другое дело, если «что-либо» это что-то кардинальное, да и к тому же конфликтующее с текущими наработками, тогда дело за ветками, о чем как-нибудь потом;
- выборка данных из хранилища. Широкие горизонты этой возможности открывает нам команды SVN Update и TortoiseSVN→Update to revision… Первая берет самую актуальную информацию об объекте для которого применена, а вторая позволяет выбрать номер правки из которой будет взята информация — машина времени в действии. Номер необходимой правки можно узнать по щелчку на кнопке Show Log. Еще к выборке можно отнести и команду SVN Checkout, которая также позволяет выбрать номер правки для выборки, но доступна эта команда только для объектов не находящихся в поле рабочей копии. Таким образом, можно всегда создать рабочую копию любой правки, что также есть путешествие во времени;
- Отмена изменений. Действия по изменению объектов рабочей копии можно отменить. Для этого существует команда TortoiseSVN→Revert…, которая заменяет объект своим кэшированным вариантом, который соответствует последней правке. Обращения к серверу не будет, кэш находится в системных директориях .svn;
Теперь, когда более или менее подробно разобраны все обычно необходимые и достаточные шаги по оперированию хранилищем и рабочей копией вы можете начать развивать собственную практику общения с SVN. Осталось немного, некоторые подводные камни и нюансы.
Подводные камни и нюансы
- Пути. Устоявшимся стандартом организации путей в хранилище является создание трех «директорий»: trunk, tags и branches, причем текущая разработка обычно находится в trunk, а остальные используются по мере надобности. Именно поэтому пути в примерах несколько странные на первый взгляд. Зачем и почему принята такая структура можно узнать из соответствующих глав книги SVN Book;
- удаление и прочие файловые операции. Если вы решили удалить или переименовать какой-то объект рабочей копии, то делайте это посредством соответствующих команд контекстного меню — изменение часть файловой системы и хранилища при последующем commit — разные вещи;
- рекурсивные свойства. Если вы добавляете в рабочую копию новую директорию, а где-то для ее предков установлено свойство с пометкой «apply property recursively», то его надо переустановить, чтобы оно было выставлено и для новой директории;
- что если ошибка? На наше счастье операции commit и update — атомарные. Это значит, что если на протяжении этих операций возникает ошибка, то операции просто не было. Это очень напоминает транзакции;
- ошибка «… probably out of date …». В случае данного сообщения попытайтесь сделать update для объекта (чаще всего это директории), обычно это помогает. Дело в то, что объект был изменен как в рабочем копии, так и в хранилище. Объект необходимо сначала обновить: update попытается объединить локальные изменения с опубликованными. Если SVN не сможет самостоятельно совершить объединение, он предложит пользователю разрешить конфликт вручную;
- ошибка при изменении комментария к правке: «DAV request failed; it’s possible that the repository’s pre-revprop-change hook either failed or is non-existent». Изменения свойств хранилища по умолчанию отключены. Для активации возможности изменять логи правок создайте в поддиректории hooks хранилища файл с именем pre-revprop-change.bat и следующим кодом:
@ECHO Off IF "%4" == "svn:log" GOTO :SVN_LOG EXIT 1 :SVN_LOG EXIT 0
- переименование объектов, сводящееся к изменению регистра символов в имени. В этом случае ошибка растет из регистронезависимости имен файлов ОС Windows. Что случается при любом переименовании файла? Клиент SVN помещает в системные поддиректории .svn переименованный файл, но также сохраняет там и старый — конфликт! Существует два пути решения такой проблемы:
- непосредственно в хранилище (рекомендуемый)
- закрепить правку;
- переименовать нужный_файл.файл, используя браузер хранилища, в Нужный_Файл.файл;
- обновить рабочую копию.
- через временный файл
- переименовать нужный_файл.файл в нужный_файл.файл_;
- закрепить правку;
- переименовать нужный_файл.файл в Нужный_Файл.файл;
- закрепить правку.
- непосредственно в хранилище (рекомендуемый)
- перемещение через переименование. В случае, когда в рабочей копии необходимо перенести объект необязательно его удалять и добавлять заново. Воспользуйтесь функцией переименования и укажите относительный путь конечной директории;
- Игнорирование родителя. Если вы занесли в игнор-лист некую директорию, то все ее дочерние элементы будут игнорироваться автоматически, что удобно при разнородном содержимом директории.
Заключение
Если вы дошли до этих строк, значит, вам это было нужно, выпейте чаю. Также возможно, что у вас просто быстрый скроллинг, но это не умаляет предыдущую мысль.
7 комментариев на «Введение в Subversion»
Оставить отзыв
Спасибо за пояснение по pre-revprop-change. В самом деле просто.
Не согласен, что TFS — старший брат VSS. Это не родственные системы. По идеологии и архитектуре они практически ничего общего не имеют. Система контроля версий TFS больше походит по функционалу на SVN (где-то отстает, где-то привосходит SVN по функционалу), чем на VSS.
Вероятно, я неточно выразился. Подразумевалась не преемственная связь, а мощностная — если нужно что-то большее, то MS предлагает в качестве решения TFS.
да, действительно, большое спасибо за pre-revprop-change, очень простое решение (непонятно, зачем нужно было делить реализацию перезаписи лога, если в DAV'е это настраивается вполне легально, выставив права пользователям)
Пожалуйста. Кстати, хотелось бы заметить, что код хука приведён для Win32, т.е. непригоден для безоговорочного использования.
Привет, из всех виденных статья лучшая и доходчивая ), но у меня не получилось настроить subversion. Установка нормально прошла, хранилище создается нормально, но вот проблемы при запуске denwer'a. До редактирования config сервер работает нормально, после раскоментирования LoadModule сервер выдает ошибку. Сами модули *.so в module/ присутствуют, в bin/ тоже есть. Кто нибуть сталкивался с таким? Как решить проблему?
nonick, ответил вам на почту.