 |
Разработка программного обеспечения без применения различных инструментов потребовала бы колоссальных затрат сил и времени. Одним из таких инструментов являются системы контроля версий, примером которых может служить Subversion – тема данной статьи.
Определение
Под системой контроля версий понимается механизм сохранения промежуточных состояний кода разрабатываемого программного обеспечения. То есть с помощью этой системы программист может управлять своими файлами во времени: смотреть историю изменений файлов и каталогов, возвращаться к более ранним версиям кода, объединять несколько версий файла. Основной областью применения контроля версий является коллективная разработка чего-либо (чаще всего это программы, но область применения программированием не ограничивается).
Однако и для разработчика-одиночки контроль версий может быть полезен.
Subversion достаточно молодая система, изначально нацеленная на замену CVS (Concurrent Versions System), которая является самой известной и распространенной системой контроля версий. Дистрибутив Subversion и всю необходимую документацию можно найти на сайте разработчиков.
Термины и понятия
Чтобы двигаться дальше, необходимо определиться с терминами и понятиями, используемыми в Subversion:
- Хранилище (Repository) – место централизованного хранения данных. Хранилище располагается на сервере и представлено в виде дерева файлов.
- Правка (Revision) – состояние хранилища в определенные моменты времени. Процесс создания правки называется «фиксация». Каждая правка имеет номер, который присваивается при фиксации.
- Ветка (Branch) – направление разработки, существующее независимо от других направлений, но имеющее общую с ними историю. Фактически представляет собой копию проекта (или его части) в определенный момент времени и совокупности фиксаций изменений. Чаще всего ветки используются для хранения различных релизов проекта. Кроме того, ветки могут применяться для изоляции группы правок, которые могут нарушить работоспособность всего кода.
- Рабочая копия (Working Copy) – копия хранилища (или его части) на рабочем месте пользователя.
Структура хранилища
В хранилище может находиться несколько проектов. В таком случае официально рекомендуется в корневом каталоге хранилища создавать для каждого проекта свой подкаталог, в который входят три подкаталога:
- /trunk – основная ветка разработки. В ней ведется большая часть разработки: внедряются новые функции, исправляются ошибки.
- /branches – различные ветки. Здесь могут храниться предыдущие стабильные релизы или располагаться наборы исправлений, решающие какую-либо определенную задачу. В общем, в этом каталоге хранятся все ветки, кроме /trunk.
- /tags – различные метки. Меткой называется поименованная правка. Физически представляет собой простую копию части хранилища в определенный момент времени. В отличие от ветки в метку нельзя выполнять фиксацию, то есть изменять ее. Наиболее часто метки используются для обозначения релизов проекта.
Все разработки по проекту ведутся в соответствующем ему каталоге. На самом деле для Subversion нет разницы между этими каталогами. Использование определенной структуры каталогов и наделение некоторых из них специальными функциями лежит исключительно в области политики и правил применения системы контроля версий.
Пример коллективной работы
В качестве иллюстрации приемов работы с Subversion ниже приведены два примера такой работы.
Трое молодых амбициозных людей собрались вместе, для того чтобы написать самую лучшую CMS. В качестве системы контроля версий разработчики выбрали Subversion.
Рабочий цикл
Простейший рабочий цикл при использовании Subversion выглядит следующим образом:
- Обновление рабочей копии. Этот шаг необходим для приведения рабочей копии в актуальное состояние.
- Внесение изменений. Этот шаг является основным в работе. На этом шаге вносятся изменения в файлы или в структуру файлов проекта.
- Анализ изменений. Этот шаг служит для контроля сделанных изменений перед фиксацией их в хранилище.
- Слияние изменений, выполненных другими, со своей рабочей копией. Этот шаг нужен для гарантии, что нет конфликтов между локальными изменениями и изменениями других разработчиков.
- Фиксация изменений. Этот шаг служит для сохранения изменений рабочей копии в хранилище. Таким образом, изменения, сделанные одним человеком, становятся доступны всем участникам проекта.
Далее каждый шаг будет рассмотрен более подробно.
Шаг 1. Утром, обсудив задачи каждого, программисты приступили к работе. Первое, что сделал каждый из них, – обновил свою рабочую копию. Сделали они это командой svn update. В результате рабочая копия каждого из разработчиков стала идентичной последней правке в хранилище.
Шаг 2. Иван решил добавить возможность регистрации пользователей. Для этого он создал новый класс /classes/user.class.php и пустой каталог для модуля /modules/user/. Василий стал расширять функциональность модуля публикации новостей, добавляя свойство «категория» к объекту «новость». А Сергей, исправляя ошибку в модуле публикации статей, обнаружил, что такая же ошибка есть и в модуле новостей, и решил ее тоже исправить.
Сергей и Василий стали редактировать соответствующие файлы в своих любимых редакторах, а Ивану пришлось совершить несколько дополнительных действий. А именно, создав файл класса и пустой каталог в каталоге модулей, Иван указал Subversion, что этот файл и каталог нужно взять под версионный контроль. Сделал он это командами:
svn add user.class.php
svn add user
Теперь файл user.class.php и каталог /modules/user/ взяты Subversion на заметку и при следующей фиксации попадут в хранилище. Если бы в каталоге user/ были бы файлы, они тоже попали бы в хранилище.
Шаг 3. Каждый из программистов, после того как закончил свою часть работы, выполнил команду svn status и убедился, что все изменения выполнил правильно.
Если после выполнения команд svn status и svn diff обнаруживается, что изменения некоторых файлов ошибочны, следует выполнить команду svn revert. Это отменит некоторые (или все) изменения и вернет указанные файлы в состояние после последней синхронизации с хранилищем.
Шаг 4. Сергей первый закончил свою работу. Он проверил правильность всех изменений, выполнил команду svn update и убедился, что конфликтов с хранилищем нет. После этого он зафиксировал свои изменения и переключился на другую задачу, начав рабочий цикл снова.
Через некоторое время Василий тоже закончил свою работу. Выполнив слияние, он обнаружил, что его изменения файла news.php конфликтуют с недавно сохраненным исправлением Сергея. Клиент Subversion Василию не только сообщил о конфликте, но и создал 3 файла (news.php.mine, news.php.r15, news.php.r16), а также пометил конфликтное место в файле news.php таким образом:
 |
То есть пометил маркерами конфликтный кусок кода. Первая часть содержит изменения Василия, а вторая часть – изменения, полученные из хранилища.
Для решения этой проблемы Василий посмотрел лог-сообщение к правке #16 (номер конфликтной правки указан в последнем маркере) и узнал, кто делал эту правку. После разговора с Сергеем Василий внес необходимые коррективы в файл (и удалил маркеры, за этим нужно следить вручную) и выполнил команду svn resolved. После чего перешел к фиксации изменений.
У Ивана ничего особенного при слиянии не произошло, и он перешел к следующему шагу.
Шаг 5. После слияния изменений каждый из разработчиков лучшей CMS выполнил команду svn commit, то еесть зафиксировал свои изменения в хранилище.
Если бы Василий не выполнил команду svn update, а сразу попытался бы зафиксировать свои изменения, то команда svn commit была бы отклонена с сообщением об устаревшем файле news.php.
Пример индивидуальной работы
Второй пример показывает положительные моменты от использования Subversion в проектах, выполняемых одним программистом.
Цикл разработки при использовании Subversion одним человеком можно упростить, опустив первый и четвертый шаги. Но только если рабочий каталог всегда один и тот же. В таком случае конфликты просто исключены.
Вернемся к примеру. Допустим, Василий пишет форум. Базовая функциональность уже готова, и он открывает форум на персональном сайте, используя свое творение. Люди стали приходить, общаться, попутно спотыкаясь о баги, которые Василий допустил.
Кроме сообщений об ошибках, пользователи форума просили Василия сделать какое-нибудь удобство, например поддержку bb-code или список новых топиков. Если бы Василий не пользовался системой управления версиями, то решение задачи поддержки старого кода и разработки новых версий, как показывает опыт, потребовало бы от него значительных усилий.
Василий, для того чтобы тратить как можно меньше времени на сопровождение разных версий своего форума, с самого начала проекта разделил версии проекта на несколько веток. В соответствии с рекомендациями выложенную на сервер версию форума Василий поместил в ветку /branches/on_server, версию с новой функциональностью перенес в ветку /trunk, а новую версию форума с полностью переписанным ядром поместил в ветку /branches/2_x.
Таким образом, если Василию нужно исправить ошибку в эксплуатирующейся версии форума, он рабочую копию берет из ветки /branches/on_server. А если решил поработать над новым ядром, то из каталога /branches/2_x. При этом большую часть работы Василий выполняет с веткой /trunk: добавляет новые функции, изменяет работу старых, исправляет найденные ошибки.
Если обнаруженная ошибка существует в нескольких ветках, то достаточно внести изменения в одну из веток, а затем объединить это исправление с другими ветками аналогично рассмотренному выше примеру со слиянием изменений нескольких программистов.
Когда Василий решает, что достаточно отладил новую версию форума и ее можно ввести в эксплуатацию, он переносит текущее состояние ветки /trunk на сервер, копирует /trunk в /branches/on_server и создает метку с текущим номером релиза, например /tag/release-1.3.
Заключение
Внедрение системы контроля версий в процесс разработки веб-проекта позволяет снизить трудозатраты и решить ряд организационных проблем как команде программистов, так и программисту-одиночке. Однако область применения Subversion не ограничивается программированием. Вот несколько задач, решение которых удобно с помощью Subversion: написание документации командой авторов (особенно географически распределенной), разработка и сопровождение сайта, состоящего только из статичных html-страниц.
В рамках одной статьи невозможно осветить все возможности и нюансы использования системы контроля версий Subversion. Для того чтобы воспользоваться всей мощью Subversion, стоит внимательно прочесть книгу «Управление версиями в Subversion» – руководство по работе с системой, написанное на основе реальных проблем пользователей. В этой книге можно найти ответы на большинство вопросов, возникающих при работе с Subversion.
Ссылки по теме
- Сайт разработчиков
- Книга «Управление версиями в Subversion»
- Subversion (статья «Википедии»)
- Система управления версиями (статья «Википедии»)
Статья получена: hostinfo.ru
Противовирусные препараты: за и против
Добро пожаловать в Армению. Знакомство с Арменией
Крыша из сэндвич панелей для индивидуального строительства
Возможно ли отменить договор купли-продажи квартиры, если он был уже подписан
Как выбрать блеск для губ
Чего боятся мужчины
Как побороть страх перед неизвестностью
Газон на участке своими руками
Как правильно стирать шторы
Как просто бросить курить
- 2410 -
