HostDB.ru
 
Логин

Пароль



или войдите через соцсеть:
провайдеров: 81, переходов на сайты провайдеров сегодня: 13

Голосование

Какую версию PHP вы сейчас используете?










Анекдот




- Версии под контролем

Версии под контролем

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

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

Subversion достаточно молодая система, изначально нацеленная на замену CVS (Concurrent Versions System), которая является самой известной и распространенной системой контроля версий. Дистрибутив Subversion и всю необходимую документацию можно найти на сайте разработчиков.

Чтобы двигаться дальше, необходимо определиться с терминами и понятиями, используемыми в Subversion:

* Хранилище (Repository). Это место централизованного хранения данных. Хранилище располагается на сервере и представлено в виде дерева файлов.
* Правка (Revision). Это состояние хранилища в определенные моменты времени. Процесс создания правки называется «Фиксация». Каждая правка имеет номер, который присваивается при фиксации.
* Ветка (Branch). Это направление разработки, существующее независимо от других направлений, но имеющее общую с ними историю. Фактически представляет собой копию проекта (или его части) в определенный момент времени и совокупности фиксаций изменений. Чаще всего ветки используются для хранения различных релизов проекта. Кроме этого ветки могут применяться для изоляции группы правок, которые могут нарушить работоспособность всего кода.
* Рабочая копия (Working Copy). Это копия хранилища (или его части) на рабочем месте пользователя.

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

* /trunk — основная ветка разработки. В ней ведется большая часть разработки: внедряются новые функции, исправляются ошибки.
* /branches — различные ветки. Здесь могут храниться предыдущие стабильные релизы или располагаться наборы исправлений, решающие какую либо определенную задачу. В общем, в этом каталоге хранятся все ветки, кроме /trunk.
* /tags — различные метки. Меткой называется поименованная правка. Физически представляет собой простую копию части хранилища в определенный момент времени. В отличие от ветки, в метку нельзя выполнять фиксацию, т.е. изменять ее. Наиболее часто метки используются для обозначения релизов проекта.

Все разработки по проекту ведутся в соответствующем ему каталоге. На самом деле для Subversion нет разницы между этими каталогами. Использование определенной структуры каталогов и наделение некоторых из них специальными функциями лежит исключительно в области политики и правил применения системы контроля версий.

В качестве иллюстрации приёмов работы с Subversion, ниже приведены два примера такой работы.

Трое молодых амбициозных людей собрались вместе для того, чтобы написать самую лучшую CMS. В качестве системы контроля версий разработчики выбрали Subversion.

Простейший рабочий цикл при использовании Subversion выглядит следующим образом:

1. Обновление рабочей копии. Этот шаг необходим для приведения рабочей копии в актуальное состояние.
2. Внесение изменений. Этот шаг является основным в работе. На этом шаге вносятся изменения в файлы и/или в структуру файлов проекта.
3. Анализ изменений. Этот шаг служит для контроля сделанных изменений перед фиксацией их в хранилище.
4. Слияние изменений, выполненных другими, со своей рабочей копией. Этот шаг нужен для гарантии, что нет конфликтов между локальными изменениями и изменениями других разработчиков
5. Фиксация изменений. Этот шаг служит для сохранения изменений рабочей копии в хранилище. Таким образом, изменения, сделанные одним человеком, становятся доступны всем участникам проекта.

Далее каждый шаг будет рассмотрен более подробно.

Шаг 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.



Опубликовано: 31.01.2011
Просмотров: 1340
Автор: killer

 
Версия для печати

Мой комментарий

Ваше имя*:
Email:
Комментарий*:
Зарегистрироваться автоматически: Вы будете зарегистрированы на сайте автоматически при добавлении комментария. Обязательно заполните поле Email для этого.
Сумма чисел 4 и 12*:            

Заявка на хостинг
Провайдеры сами пришлют
вам свои предложения ;)


Проверка IP

Ваш IP ....... 35.153.156.108 ← Проверить
Страна ..... не определена

Проверка домена (+whois)













Выбрать все
Расширенный поиск (более 50 зон)

Traceroute

Начало маршрута



Быстрый хостинг Fozzy

Акции провайдеров

Все акции хостинг провайдеров


БЕСПЛАТНЫЙ КОНСТРУКТОР САЙТОВ И LANDING PAGE