Данная статья основывается на предыдущей, а также на мысли, что лучший способ что-либо понять — сделать это самому.

Что такое ветвление

Ветвление (branching) SVN — это именно то, что стоит за этим словом: создание ветвей. Ничем большим или меньшим это понятие не обладает.

То чем мы занимались до этого (см. статью «Введение в Subversion»), было движением по единственной координате — времени. Однако представьте себе некий проект, в котором одновременно идет работа по многим направлениям разом, но в неком одном общем. Например, это может быть разработка «ПрограммаХ», когда один отдел работает над известными ошибками, другой занимается разработкой плагинов, а третий работает по главному вектору разработки. Вся работа, проделываемая ими, сказывается на разнице «ПрограммаХ» от самой себя, например, в какой-то момент времени в основной версии программы содержится некая ошибка, в то время как в версии отдела по борьбе с ошибками ее уже нет.

краткий итог:

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

Зачем нужны ветки

Представьте себе, что вам поручили оптимизировать схему подключения к основной программе плагинов. Или другой случай — в вашей среде разработки принято делать технический релиз в субботу вечером, чтобы группа по работе над качеством могла приступить к своему делу в понедельник. Как бы то ни было, из-за того, что потребуется внести много мешающих основной линии разработки изменений, самое эффективное решение — создание отдельной ветки, в то время как в основной не прекращает кипеть работа по своим графикам. Суть в примерах только в том, что они порождают различные «типы» веток. Таких несколько:

• Функциональные ветки;
• Ветки релизов;
• Метки.

это принципиально:

Тип ветки — условное понятие. С точки зрения SVN любая ветка — это обычная директория в хранилище. То, что делает эту директорию тем или иным типом ветки находится в вашем ее восприятии. Это порой путает, но является исключительно простым по сути, надо только запомнить.

Именно наличие нескольких типов веток и объясняют странную на первый взгляд структуру хранилища по умолчанию:

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

Функциональные ветки

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

Метки

Может возникнуть вопрос о причине вынесения меток в отдельную директорию. Дело в том, что обычно это просто ссылка на ту или иную правку какой-либо ветки. Почему ссылка? Вспомните, что говорилось о «дельте данных» в предыдущей статье. Точно такая же схема используется и при создании ветки, а в случае метки — копии ветки. Т.к. при создании метки ничего нового не появляется «дельта» по сути равна нулю и создаются просто ссылки на объекты ветки из которых создается метка. Таким образом, метки уменьшают многословность и неопределенность вида «ветка branches/version_3.14@364» сводя ее к примерно следующему «tags/october» — октябрьский релиз. Данные при этом не копируются, хранилище не растет вширь, навигация по множеству релизов упрощается. Совокупность меток, релизов, а при необходимости и функциональных веток, помогает организовать работу для решения задачи из второго примера в начале этой главы.

краткий итог:

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

Использование веток

Разберемся с ветвлением на примере движка блога WordPress, сопровождая процесс знакомства временными диаграммами правок хранилища и иллюстрациями изменяющейся файловой структуры проекта.

Пусть нашей целью будет обновление WordPress v2.2.3 на v2.3.0. Также предположим, что в нашем распоряжении имеется хранилище, расположенное по адресу http://127.0.0.1/svn/web-dev причем со структурой директорий как это рассматривалось выше. Главная ветка разработки с номером правки 35 содержит WordPress v2.2.3.

уступка реальности:

для тех, кто имеет дело с WordPress не секрет, что переход на v2.3.0 сопряжен также и с изменением БД ввиду введения в понятие движка меток-тегов. Также не во всех случаях обновление возможно простым «копированием поверх». Для упрощения примера опустим эти тонкости. Вопрос синхронного закрепления в хранилище, как файлов, так и содержимого БД — предмет дальнейшей статьи «smarty commit».

Таким образом, начальная картина хранилища и ее временная диаграмма будут иметь вид:

Каковы будут действия для выполнения поставленной задачи:

1. Создадим метку tags/v223 для текущего состояния trunk — по сути именованный backup;
2. Создадим ветку branches/v230 на основе trunk — поле деятельности, в котором и будет происходить файловые операции по обновлению WordPress;
3. Выполним все операции, требующиеся для обновления;
4. Сольем trunk и branches/v230 чтобы в будущем вести в trunk работу над v2.3.0.

Создание

Создание ветки осуществляется обычным копированием того, что будет ответвлено (обычно это trunk) в ту директорию хранилища, которая соответствует типу создаваемой ветки.

чтобы никто не ошибся:

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

Обратимся к нашему примеру, где для начала необходимо создать метку. Откройте хранилище http://127.0.0.1/svn/web-dev посредством пункта контекстного меню TortoiseSVN→Repo-browser на любой директории любого локального диска. Выделите директорию trunk и для команды контекстного меню Copy to… задайте адрес http://127.0.0.1/svn/web-dev/tags/v223. Копирование произойдет очень быстро т.к., по сути, никакие данные не копируются, о чем уже говорилось выше. Ветка успешно создана, а о том, что это метка говорит нам только ее месторасположение.

на заметку:

При каждом создании ветки создается новая правка, именно поэтому в нашем примере номер правки с которой метка начинает жить самостоятельно — 36.

Для того чтобы выполнить второй пункт нашего алгоритма повторите действия по созданию ветки (сначала, если вы поспешили закрыть браузер хранилища), но конечной целью укажите branches/v230.

можно иначе:

клиент TortoiseSVN предоставляет альтернативный способ ветвления посредством команды TortoiseSVN→Branch/Tag… Смысл у нее тот же самый, все изменения также производятся на стороне хранилища без передачи данных клиенту, и команда, по сути, является просто быстрым способом создания ветки без обозревания хранилища.

Мы добились некоторых результатов, которые можно было бы отразить следующим образом:

краткий итог:

Ветка — копия чего-либо. Но технически копия «легкая». Это означает, что при ее создании создается новая правка, все объекты которой указывают (ссылаются) на объекты предыдущей правки. Настоящее копирование произойдет только при изменении чего-либо в ветке. Все это напоминает обычное закрепление изменений и по сути таковым и является, с той лишь разницей, что добавляется дополнительная информация об истории.

Изменение

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

Теперь, когда у нас есть новая ветка branches/v230 мы можем поступить по-разному:

1. Сделать checkout ее содержимого в какую-то директорию и начать с ней работать;
2. Переключить нашу, уже существующую рабочую копию, которая указывает на trunk так, чтобы она стала отражать содержимое branches/v230;
3. Скопировать рабочую копию trunk в какую-нибудь директорию и поступить с ней как это описано в предыдущем пункте.

Первый способ в большинстве случаев будет удобен пользователям denwer ввиду возможности автосоздания виртуальных хостов — очень удобно произвести выгрузку ветки в отдельную директорию в home комплекса, перезагрузить его и работать в отдельной ветке с возможностью всегда изменить и копию соответствующую trunk.

чтобы никто не забыл:

Мы исходим из web-ориентированности повествования. У нас тут всякие Apache и прочие www.

Третий вариант является частным случаем второго, который, в свою очередь, будет работать максимально эффективно при следующих условиях:

• Нет необходимости работать одновременно в нескольких рабочих копиях разных ветвей;
• Хранилище расположено удаленно;
• Переключение предполагается произвести между trunk и только что созданной на ее основе ветки.

Первый пункт обуславливает меньшее количество телодвижений — не надо ничего создавать, выгружать, конфигурировать, перезагружать (если вы используете не denwer) и прочее. Последний пункт экономит наш трафик при условии выполнении второго пункта и просто время, если это не так. Дело во все той же «дельте» — при создании рабочей копии мы передали бы некоторую часть хранилища полностью, в то время как при переключении — только разницу, которая в этом частном случае теоретически равна нулю.

о вечном:

В теории все замечательно, однако на практике немного информации все же передается, но по сравнению с checkout ее объем пренебрежительно мал.

Так как в способе первом ничего интересного нет, попытаемся освоить другой метод. Освоение будет заключаться в выполнении над рабочей копией trunk команды TortoiseSVN→Switch… с указанием того на что мы будем переключаться branches/v230. После завершения операции рабочая копия будет представлять собой содержимое этой самой ветки, update, commit и некоторые прочие операции по умолчанию будут работать уже не с trunk, а с branches/v230. В общем, произошло нечто ожидаемое — переключение на другую ветку разработки без утомительных выгрузок в новую рабочую копию и прочего. Теперь можно работать, как это делалось прежде. Для нашего примера это все необходимые действия по обновлению WordPress — копирование поверх обновленных файлов движка, проверке все ли в порядке, доводка напильником и прочими подручными средствами. Естественно, что в ходе этих действий можно и нужно использовать всю мощь SVN: update, commit, revert и прочее.

если подумать:

Команды switch и update очень похожи — обе изменяют рабочую копию на основе анализа хранилища. На самом деле update является частным случаем switch, которая может сравнивать и изменять текущую рабочую копию с различными ветками в хранилище. Это более гибкий и мощный инструмент. Оправданием существования update может послужить то, что это менее гибкий и мощный инструмент.

Для того чтобы продолжить линию нашего примера представим, что в ходе изменений было создано 7 правок и мы остановились на правке №44:

Копирование изменений между ветками

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

То как часто это следует делать, необходимо ли делать вовсе и прочие вопросы, связанные с этой операцией решаются исходя из типа ветки, внутренней политики разработки и чувства меры. Например, самый распространенный случай, когда имеется главная ветка разработки и несколько функциональных ветвей. Тогда если в ветвях делаются изменения по каким-то причинам выходящие за рамки целей создания этих ветвей, их необходимо копировать в главную ветку разработки как можно скорее. Примером такого рода изменений может служить обнаруженная и исправленная ошибка, в то время как ветки не предназначались для их отлова и исправления. Как видно существует довольно много «если» и вопрос своевременности копирования изменений из ветки в ветку по праву можно считать тонким.

из чувства справедливости:

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

Копирование части изменений

Пусть в ходе работ по обновлению было выяснено, что в обеих ветках (trunk и branches/v230) в файле www/wp-config.php, который не был перезаписан обновлением, была замечена ошибка. Таким образом, ошибка содержится в обеих ветках. Предположим, что мы справили ее в текущей на данный момент branches/v230, и закрепили исправление в правке №44. Задача состоит в копировании исправления в tags/v223.

Предыдущая мысль — типичный пример засады, которые встречаются на пути не только начинающих пользователей SVN. Ошибка заключается в предании забвению факта, что все правки любой из веток — фотографии, слепки всего дерева хранилища на какой-то момент времени, а значит, мы не можем изменить уже закрепленные правки — tags/v223 «потеряна» для нас. К тому же эта метка, как и другие ветки, живет отдельно и изменения в ней не будут видны, например пользователям trunk.

Следует поступить по следующей схеме:

• Портировать изменения в самую общую ветвь — trunk, обязательно указав в комментарии, что это порт и описав его суть, чтобы для людей пользующихся одновременно trunk и branches/v230 не поставил в тупик неожиданный могущий возникнуть конфликт;
• Удалить tags/v223 или оставить ее на месте;
• В зависимости от выбранного действия над tags/v223 нужно или портировать в нее изменения из trunk, или создать на основе trunk новую метку, назвав ее, например, tags/v223_patched1 с комментарием о сути патча.

Теперь у нас полный порядок в логике и хоть сказанное выше звучит устрашающе, но на практике все очень просто.

Портирование изменений осуществляет консольная команда svn merge или ее представитель TortoiseSVN→Merge…. Команда принимает адреса сравниваемых деревьев и рабочую копию, к которой разница между деревьями будет применена в виде локальных (!!!) изменений. Потом их можно будет закрепить или отменить.

Ветви, которые участвуют в портировании изменений, дадут адреса деревьев, а направление ответит на вопрос к рабочей копии какой ветки применять разницу. В нашем примере from — http://127.0.0.1/svn/branches/v230/www/wp-config.php, to — также http://127.0.0.1/svn/branches/v230/www/wp-config.php, а рабочая копия для ветки trunk.

обратите внимание:

В качестве деревьев выступает один единственный файл, частный случай обуславливаемый названием и смыслом текущей главы.

Адреса деревьев будут не полными без указания номеров правок. Это уточняющая координата. Обратимся к логике: мы условились, что исправления, которые мы должны портировать, закреплены в правке №44, а значит, в правке №43 их не было. Следует вывод, что диапазон номеров правок будет 43-44. Это все необходимые данные.

чтобы не ошибиться:

Рекомендуется запускать тестовое слияние посредством кнопки «dry run» перед тем как запустить его по-настоящему.

Теперь исправление ошибки находится в ветке trunk под правкой №45, но оно никак не отражено в метке tags/v223. Логично хранить все изменения в одном месте, значит, ничего удалять не будем, а портируем только что портированные в trunk изменения и туда. В этом случае адрес дерева from будет таким же, как и в предыдущем портировании, to — аналогично. Диапазон номеров правок также останется без изменений. Изменится лишь рабочая копия, которая должна будет отражать состояние tags/v223. В этом нам поможет уже известная нам TortoiseSVN→Switch…. Теперь все логически верно: все состояния, на которые можно откатиться при неудачном обновлении WordPress до v2.3.0, у нас находятся в tags/v223, причем с возможностью выбора момента отката — до исправления ошибки (правка №36) и после ее портирования (правка №46).

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

Обратите внимание на жирную линию со штрихом. Это альтернативный способ портирования изменений в tags/v223 достигаемый при параметрах from и to равными http://127.0.0.1/svn/trunk/www/wp-config.php, с диапазоном правок 35-45. Аналогичный результат даст команда и для правок 35-44 при неизменном адресе сравниваемых деревьев. Это обусловлено тождественностью правок 44 и 45. Как видите, результата можно достигнуть множеством путей. Однакое необходимо заметить, что эти способы работают только в конкретном случае примера, когда между правками 35 и 37 не было изменений trunk, что помешало бы использованию альтернативных способов, но об этом ниже.

краткий итог:

При слиянии необходимо всегда руководствоваться логикой и запомнить, что merge выполняется для двух деревьев хранилища заданных адресами и диапазоном правок, а разница всегда применяется к рабочей копии или части ее, если команда была выбрана не для всей копии. Никакие изменения в хранилище при этом не вносятся — вам нужно будет сделать это самостоятельно позже обычным commit, если потребуется. Сломать что-либо слиянием очень сложно, хотя запутаться есть где. Затем и логика.

Слияние веток полностью

Мы только что закончили все операции по обновлению WordPress до v2.3.0 и остались довольными качеством работы. Время за слиянием функциональной ветки branches/v230 в основную линию разработки trunk.

Опять прибегаем к логике: необходимо сравнить trunk@35 и branches/v230@44 чтобы получить разницу которую надо применить к trunk. Для нашего конкретного случая это сработает, все верно. Но это ошибочный путь, не думайте в таком ключе. Представьте себе, что кто-то из ваших товарищей все это время работал над trunk и вносил туда изменения. Тогда при попытке вычислить разницу между trunk@35 и branches/v230@44 вы засечете и его изменения, которые, пересекаясь с вашими, могут дать непредсказуемые результаты. Гораздо легче и безопаснее сравнивать branches/v230@37 и branches/v230@44, что оправдано и логически: взять все изменения в ветке branches/v230 с момента ее создания до последней правки.

Самое «сложное» — определить начальную правку ветки. Делается это посредством просмотра лога ветки при выбранной опции «stop on copy/rename», что в свою очередь достигается через контекстное меню нужной ветки в repo-browser.

Остальные моменты слияния ничем не отличаются от уже делавшихся нами в предыдущей части этой статьи.

для внимательных:

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

Теперь ветку branches/v230 можно удалить или оставить и создать метку tags/v230, что уже не является сложной задачей.

Подводные камни и нюансы

1. Ветки — простые копии;
2. Можно переключать с ветки на ветку не только всю рабочую копию, но и один единственный файл или директорию. Все, что необходимо — знать, что только с ними будет вестись работа. Также имеется возможность переключаться и на любую правку ветки;
3. Обязательно комментируйте портирование изменений вплоть до номеров правок — это поможет вам в ряде случаев. Например, предположим, что branches/v230 не была удалена после полного слияния с trunk и в ней продолжилась работа, которая привела к появлению правок 48-55. Пусть необходимо также портировать эти изменения в trunk. В этом случае по комментариям в логе хранилища легче всего определить, что первая волна изменений охватывала правки 37-44 и была закреплена в правке 47. Значит, вторая волна должна охватывать правки 48-55 и никак не 37-50, что приведет к захвату изменений первой волны дважды;
4. Никто не обязывает вас делать хранилище со структурой, о которой говорилось в этой статье. Организация хранилища – личное дело каждого. Однако стоит помнить, что вещи проверенные временем заслуживают внимания;
5. Совсем не обязательно иметь на локальной машине такую же структуру, как и у хранилища. Может случиться, что у вас на компьютере в один момент времени будет лишь одна рабочая копия, расположенная в неком DocumentRoot некоего сайта и вы будете интенсивно использовать svn switch для доступа к иным местам хранилища. Экономьте свое место на диске и время.

Заключение

Ветки — это просто. Все, что необходимо в работе с ними — логика и четкое понимание происходящего. Ну и практика, конечно. Не опасайтесь их, просто используйте.

В этой статье мы поговорим, установим и попытаемся использовать в своих корыстных целях одну из разновидностей СКВ — 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-сервера на другом порту.

Сравнение двух первых способов можно видеть в таблице ниже:

Оба вышеописанных варианта подразумевают, что доступ к хранилищам будет предоставляться на основе парадигмы «клиент-сервер». Это частая ситуация когда разработчиков много. Однако нередко нужно развернуть систему контроля версий без подобных сложностей. В таком случае потребуется только клиент — программа необходимая в любом случае. У подхода есть один минус — файловая система, на которой находится хранилище, должна быть локальной.

краткий итог

Если заниматься разработкой 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

Примечание

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

Разберемся со всем по порядку:

1. Создание хранилища;
2. предимпортная настройка;
3. импорт проекта в хранилище;
4. создание рабочей копии;
5. редактирование рабочей копии;
6. закрепление изменений (правки);
7. выборка данных из хранилища;
8. отмена изменений.

Для того чтобы различные действия были понятны договоримся каждый из шагов снабжать популярным объяснением которое будет основано на двух персонажах:

• Разработчик — человек, который выполняет работу. К такой работе сводится создание, удаление, изменение файлов составляющих некий продукт или гордость за все вместе взятое;
• Лидер — человек, который определяет линию разработки, а также обеспечивает наличие всех необходимых в разработке вещей, например, данных.

Подобная, очень упрощенная, организация процесса труда принята для повышения эффективности разработки в целом. Но представьте себе ситуацию, когда разработчик, например в ситуации с личным блогом, один. Никто не возьмет на себя роль лидера, ее придется выполнять самостоятельно. Поэтому, если какие-то действия покажутся вам странными и непонятными, попытайтесь распределить роли и все встанет на свои места.

1. Создание хранилища. Хранилище или иначе репозиторий — особое место, где SVN в собственном формате хранит все наши данные в виде правок. Директорией, где мы решили разместить хранилища, будет d:\www\svn_repository, а хранилище будет называться web-dev. Тогда создаем директорию d:\www\svn_repository\web-dev и через контекстное меню для нее выбираем TortoiseSVN→Create repository here… Тип репозитория должен быть FSFS. Хранилище создано и готово к работе;
   

   метафора

   Этот шаг можно сравнивать с примерным лидером который готовит рабочее место для разработчика наряду с созданием ftp аккаунтов и прочих подобных вещей.

2. Предимпортная настройка. Этот шаг опционален и не является каноническим, однако я бы порекомендовал делать его всегда, когда его есть к чему применить. Речь пойдет о настройке рабочей копии в плане задания свойства игнорирования файлов, для которых не нужно хранить информацию о версии (версионировать). Примером таких файлов могут быть «скомпилированные» шаблоны Smarty, файлы проекта редактора PhpED, дампы баз и прочее, что по каким-то причинам расположено в рамках рабочей копии, но не нуждается в отслеживании изменений. Создайте простую копию проекта, а в оригинале удалите все то, что не считаете нужным отдать под версионирование. Пока это все;
   

   метафора

   Лидер уже располагает какими-то данными, но он также понимает, что не все из них нужно отдавать в хранилище даже если эти «излишки» нужны в работе. Своими действиями он готовит чистую заготовку рабочей копии без всякого мусора — базовую редакцию.

3. Импорт проекта в хранилище. Здесь необходимо сообщить хранилищу базовую редакцию проекта на основе которой он будет, подобно пирамиде из правок (часто очень причудливой — подумайте о ветвлении), хранить наши изменения. Пусть это будет проект блога в котором размещена эта статья: 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, то по ее поводу забегите немного вперед, если вам интересно.

   В зависимости от объема импортируемых данных зрелище будет более или менее впечатляющее… и длительное;

   метафора

   Лидер создает фундамент на котором силами разработчика будет строиться вся разработка. Таковым фундаментом является первая правка в хранилище — результат прошедшего импорта.

4. Создание рабочей копии. Теперь самое время… удалить оригинал вашего проекта.
   

   Внимание!

   До тех пор пока не будете уверенно использовать SVN, всегда делайте резервирование данных проекта привычным для вас образом. В процессе обучения, чтобы начать все с чистого листа, обычно не раз удаляется хранилище — а значит и резервные копии.

   Делается это потому, что оригинал проекта не содержит еще данных о версиях файлов, а значит, не является рабочей копией. Директорию нужно таковой сделать. Для этого и производится удаление, чтобы потом создать под этим же именем директорию, которая будет рабочей копией с точки зрения SVN и файлами, составляющими блог, с точки зрения Apache. Далее, для пустой директории web-dev.info запустите команду контекстного меню SVN→Checkout…, URL хранилища нужно взять из предыдущего шага: http://127.0.0.1/svn/web-dev/trunk. Теперь, после завершения, у вас есть рабочая копия вашего хранилища, с которой можно производить любые действия, вплоть до забрасывания проекта;

   метафора

   Лидер продолжает заботиться о разработчике и делать свою работу. На этом этапе он создал собственную рабочую копию т.к. необходимо навести порядок с файлами, исключенными на этапе предимпортной настройки. Тем, что над лидером нет никого, кто сделал бы эту работу для него и обусловлена эта чехарда с удалением оригинала и созданием пустой директории.

5. Редактирование рабочей копии.
   Тут можно дать волю фантазии, например, отбросить ее в сторону и заняться делом. Под редактированием понимается любое изменение содержимого файлов, их переименование, изменение свойств и прочее. Все эти телодвижения скажутся на рабочей копии так, что нам надо будет их сохранить, а в терминах SVN — закрепить. Давайте потратим нашу первую правку на что-нибудь полезное: второй этап настройки списка игнорируемых объектов. Мысленно вернитесь к этапу предимпортной настройки. По его результатам у нас имеется оригинал, ставший после последующих шагов рабочей копией и старая резервная копия. Скопируйте резервную копию поверх рабочей копии. выполните для последней команду TortoiseSVN→Check for modifications и вы увидите все файлы, которые решили не версионировать с пометкой «non-versioned». Можно отметить их как игнорируемые, в чем клиент предоставляет нам довольно большую свободу посредством контекстного меню, вызываемом при клике правой кнопкой мыши на не версионированных объектах. Дело за вами и пусть эти изменения будут пока единственными;

   метафора

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

6. Закрепление изменений. Действие сводится к выбору команды контекстного меню SVN Commit… Причем для какого объекта вы ее выбрали, тот и будет закреплен. Это открывает большие возможности по ветвлению в рамках одной ветки: можно разбить ряд внесенных изменений по правкам. Commit для всей рабочей копии, естественно приведет к закреплению всех изменений, что вы и сделали в конце предыдущего шага. Вообще, закрепление изменений рекомендуется делать осмысленно. Не раз в день, не каждые 3.14 минуты, а по задаче. В качестве примера, локализация плагина WordPress — отличная вещь, умещающаяся в одной правке. А вот локализацию большего их числа лучше разбить на несколько. Идея проверить что-либо «на живую» тоже вполне втиснется в рамки одной правки. Другое дело, если «что-либо» это что-то кардинальное, да и к тому же конфликтующее с текущими наработками, тогда дело за ветками, о чем как-нибудь потом;
7. выборка данных из хранилища. Широкие горизонты этой возможности открывает нам команды SVN Update и TortoiseSVN→Update to revision… Первая берет самую актуальную информацию об объекте для которого применена, а вторая позволяет выбрать номер правки из которой будет взята информация — машина времени в действии. Номер необходимой правки можно узнать по щелчку на кнопке Show Log. Еще к выборке можно отнести и команду SVN Checkout, которая также позволяет выбрать номер правки для выборки, но доступна эта команда только для объектов не находящихся в поле рабочей копии. Таким образом, можно всегда создать рабочую копию любой правки, что также есть путешествие во времени;
8. Отмена изменений. Действия по изменению объектов рабочей копии можно отменить. Для этого существует команда TortoiseSVN→Revert…, которая заменяет объект своим кэшированным вариантом, который соответствует последней правке. Обращения к серверу не будет, кэш находится в системных директориях .svn;

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

Подводные камни и нюансы

1. Пути. Устоявшимся стандартом организации путей в хранилище является создание трех «директорий»: trunk, tags и branches, причем текущая разработка обычно находится в trunk, а остальные используются по мере надобности. Именно поэтому пути в примерах несколько странные на первый взгляд. Зачем и почему принята такая структура можно узнать из соответствующих глав книги SVN Book;
2. удаление и прочие файловые операции. Если вы решили удалить или переименовать какой-то объект рабочей копии, то делайте это посредством соответствующих команд контекстного меню — изменение часть файловой системы и хранилища при последующем commit — разные вещи;
3. рекурсивные свойства. Если вы добавляете в рабочую копию новую директорию, а где-то для ее предков установлено свойство с пометкой «apply property recursively», то его надо переустановить, чтобы оно было выставлено и для новой директории;
4. что если ошибка? На наше счастье операции commit и update — атомарные. Это значит, что если на протяжении этих операций возникает ошибка, то операции просто не было. Это очень напоминает транзакции;
5. ошибка «… probably out of date …». В случае данного сообщения попытайтесь сделать update для объекта (чаще всего это директории), обычно это помогает. Дело в то, что объект был изменен как в рабочем копии, так и в хранилище. Объект необходимо сначала обновить: update попытается объединить локальные изменения с опубликованными. Если SVN не сможет самостоятельно совершить объединение, он предложит пользователю разрешить конфликт вручную;
6. ошибка при изменении комментария к правке: «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

7. переименование объектов, сводящееся к изменению регистра символов в имени. В этом случае ошибка растет из регистронезависимости имен файлов ОС Windows. Что случается при любом переименовании файла? Клиент SVN помещает в системные поддиректории .svn переименованный файл, но также сохраняет там и старый — конфликт! Существует два пути решения такой проблемы:
   • непосредственно в хранилище (рекомендуемый)
     • закрепить правку;
     • переименовать нужный_файл.файл, используя браузер хранилища, в Нужный_Файл.файл;
     • обновить рабочую копию.
   • через временный файл
     • переименовать нужный_файл.файл в нужный_файл.файл_;
     • закрепить правку;
     • переименовать нужный_файл.файл в Нужный_Файл.файл;
     • закрепить правку.
8. перемещение через переименование. В случае, когда в рабочей копии необходимо перенести объект необязательно его удалять и добавлять заново. Воспользуйтесь функцией переименования и укажите относительный путь конечной директории;
9. Игнорирование родителя. Если вы занесли в игнор-лист некую директорию, то все ее дочерние элементы будут игнорироваться автоматически, что удобно при разнородном содержимом директории.

Заключение

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