Введение

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

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

В этой статье речь пойдет о cvs (concurrent versions system) - одной из систем управления версиями, существующих на рынке. Я впервые начал использовать cvs около трех лет назад, программируя на delphi, но имея довольно плотный опыт работы под linux. С тех пор я сменил область деятельности на программирование для web, участвовал в проектах с несколькими разработчиками, и использовал cvs в каждом своем проекте, сколь бы невелик он был, и даже сколь мало он ни был бы связан с собственно программированием. Признаться, сейчас я вообще не представляю себе, как можно программировать, если не контролируешь собственные исходники: даже этот небольшой текстовый файл со статьей уже имеет ревизию 1.1.

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

Повседневное использование

Если ваша операционная система - linux, то, скорее всего, cvs уже установлена на вашей машине или же может быть установлена в мгновение ока с помощью менеджера пакетов. Если вы используете windows, то сходите на http://www.cvsgui.org/, и скачайте там клиента и графическую оболочку к нему (если хотите). Создайте репозиторий, руководствуясь инструкциями из обширной документации к cvs.

Теперь начнем создавать где-нибудь в отдельном каталоге (не каталоге с репозиторием!) рабочую копию. Создадим каталог для нашего проекта:

$ cvs co -l .
$ mkdir hello

и поместим его в репозиторий:

$ cvs add hello
directory /home/cvsroot/hello added to the repository

Создадим внутри этого каталога файл с нашей программой:

=== hello.c ===
#include
int main() {
printf("hello worldn");
}
=== hello.c ===

и поместим этот файл под контроль версий:

$ cvs add hello.c
cvs add: scheduling file `hello.c' for addition
cvs add: use 'cvs commit' to add this file permanently

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

$ cvs commit -m "first revision" hello.c
rcs file: /home/cvsroot/myproject/hello.c,v
done
checking in hello.c;
/home/cvsroot/myproject/hello.c,v <-- hello.c
initial revision: 1.1
done

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

=== hello.c ===
#include
int main() {
printf("hello, world!n");
}

=== hello.c ===
Что же изменилось? Спросим у cvs:
$ cvs diff -u hello.c
index: hello.c
===================================================================
rcs file: /home/cvsroot/myproject/hello.c,v
retrieving revision 1.1
diff -u -r1.1 hello.c
--- hello.c 2001/01/23 22:16:35 1.1
+++ hello.c 2001/01/23 22:19:08
@@ -1,5 +1,5 @@
#include
int main() {
- printf("hello worldn");
+ printf("hello, world!n");
}

Вот в таком вот формате ("унифицированном diff-формате") cvs показывает нам изменения, произошедшие с файлом с того момента, когда он последний раз "фиксировался" в репозиторий. Легко видеть, что одна строка в файле была изменена: мы видим ее старое и новое состояния. Теперь, когда приветствием, выводимым программой, будет доволен любой корректор, можно зафиксировать и это изменение с помощью все той же команды:

$ cvs commit -m "improved greeting" hello.c

Описание команд cvs выходит за рамки этой небольшой статьи, но в конце ее приведены ссылки на материалы, в которых эта тема обсуждается с недостижимой здесь полнотой. Я же вернусь к более абстрактному описанию сосуществования с системой контроля версий. Первое время, довольно продолжительное, можно безболезненно работать с буквально полудесятком команд cvs:
добавление файла в проект (cvs add);
удаление его из проекта при помощи команды cvs remove (заметьте, что вся история изменений в этом файле будет сохранена!);
просмотр изменений (cvs diff);
фиксация изменений в репозитории (cvs commit);
на должность пятой команды в данном случае претендуют почти все остальные команды в зависимости от личных предпочтений.

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

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

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

Несколько ветвей разработки

Через несколько месяцев, когда вы более-менее освоитесь с повседневным использованием cvs, вам все чаще станут вспоминаться виденные когда-то в документации и в речи старших товарищей словосочетания "стабильная ветка", "сольем изменения на ствол", "поддержка старых версий". Это означает, что вы уже готовы программировать одновременно две версии своей программы. Одна - стабильная, которая уже работает у заказчика, но время от времени требует небольших исправлений или доработок. Вторая - та, разработку которой вы продолжаете, которая будет называться версией 2.0, содержит новые возможности или вообще почти полностью переписана. На помощь приходит cvs, которая с самого начала разрабатывалась для поддержки нескольких ветвей разработки программы.

В какой-то момент вы объявляете, что выпущена hello version 1.0. Дистрибутив программы отправлен пользователю, а вам самое время приготовиться к дальнейшей разработке. Пометьте текущее состояние исходников:

$ cvs rtag hello-1-0-release hello

Во-первых, теперь вы всегда сможете вернуться к состоянию программы на момент релиза с помощью команды

$ cvs co -r hello-1-0-release hello

Во-вторых, что важнее, теперь вы сможете создать ветку разработки, в которой будете вести поддержку программы (выпуская версии 1.01, 1.02 и т. д.). Для этого используется команда cvs rtag с ключом -b:

$ cvs rtag -b -r hello-1-0-release hello-1-0 hello

Теперь в вашей текущей рабочей копии можно продолжать активную разработку hello version 2. Одновременно с этим от пользователя начнут поступать запросы на исправление ошибок, небольшие доработки etc. Создайте себе еще одну рабочую копию в каталоге hello-support:

$ cvs co -r hello-1-0 -d hello-support hello

Эта рабочая копия "помнит" о том, что при ее извлечении использовался идентификатор ветки (hello-1-0), и теперь все исправления, которые вы сделаете и зафиксируете, окажутся именно на ветке, не затрагивая основной ствол разработки. И наоборот, изменения, вносимые в вашу основную рабочую копию, не окажут влияния на ветки, которые существуют в репозитории.

Несколько разработчиков

cvs изначально разрабатывалась с учетом возможности работы над проектом нескольких разработчиков. Дело в том, что вы можете извлечь из одного репозитория несколько рабочих копий -- по одной на каждого программиста. Очевидно, что в большинстве случаев разные программисты будут работать над разными частями проекта. Каждый из них будет фиксировать изменения в своей части проекта, и они не станут натыкаться друг на друга в репозитории. Для того чтобы получить изменения, сделанные другими, нужно специально вызвать команду

$ cvs update

Если вдруг случайно Петя и Вася бросятся исправлять один и тот же кусок кода, и сделают это по-разному (сама по себе эта ситуация указывает на недостаток общения Пети и Васи друг с другом), то cvs обработает и эту ситуацию. Когда Петя зафиксирует свое исправление, cvs позволит ему сделать это. Когда Вася попытается зафиксировать свой вариант исправления, cvs обнаружит, что эти исправления перекрываются, и предложит ему обновить рабочую копию с помощью cvs update. Эта команда покажет, что в исправляемом файле произошел так называемый "конфликт" и пометит место конфликта в рабочей копии этого файла. Предположим, Петя решил, что важнее исправить синтаксис выводимого сообщения, а Вася -- что нужно использовать более простую функцию puts(). Конфликт будет выглядеть примерно так:

<<<<<<<<
printf("hello, world!n");
=========
puts("hello world!");
>>>>>>>>

Васе следует обсудить с Петей причину конфликта, договориться, какое из изменений важнее (или просто объединить их), затем убрать индикаторы конфликта (строчки из символов "больше", "меньше" и "равно"), оставить лучший из двух вариантов и, если нужно, зафиксировать окончательное изменение.

Многие пугаются, услышав о полуавтоматической обработке конфликтов. На самом деле практика показывает, что при совместной работе с использованием cvs конфликтов практически не возникает (я говорю на основании опыта двухмесячной работы трех программистов над одним проектом). За эти два месяца я наблюдал, ну может быть, три или четыре конфликта. Все они были простейшими и исправлялись за три минуты. Никаких проблем, связанных с совместной работой, замечено не было.

Заключительная часть

cvs необычайно широко применяется при разработке подавляющего большинства современных проектов с открытым исходным текстом. Среди огромного списка операционных систем и программ: freebsd, xemacs, xfree86, openssl, выделяется, пожалуй, лишь ядро linux, главный разработчик которой, Линус Торвальдс, в силу особенностей личности отказывается использовать какую бы то ни было систему управления версиями, кроме собственного мозга. Да и то, почти все остальные участники разработки держат свой собственный cvs-репозиторий, которым активно пользуются при разработке (здесь им помогает интересная возможность cvs: т. н. "ветки поставщика" (vendor branches)). Проект http://sourceforge.net/, обеспечивающий свободно доступную инфраструктуру для разработчиков свободного программного обеспечения, в качестве стандартной возможности предоставляет использование своего cvs-сервера. Вообще, количество инсталляций и пользователей -- одно из значительных преимуществ cvs.

Альтернативы

На рынке свободно распространяемых программ cvs практически нет конкурентов. Однако из-за почтенного возраста (первые версии cvs появились в 1986 г.) появилась небольшая, но ясно видная ниша для конкурирующих продуктов. Дело в том, что cvs не поддерживает несколько удобных (некоторые даже считают их критичными) возможностей, например, версионность каталогов - отслеживание истории файлов с учетом их переименования, а также поддержку "наборов изменений" (changesets). Кроме того, разработка cvs в последнее время несколько приостановилась, в нем давно не появляется новых крупных возможностей (впрочем, это не означает, что существующих возможностей не хватает). Есть несколько коммерческих продуктов, поддерживающих примерно тот же набор возможностей, что и cvs. Два, на мой взгляд, самых известных - это perforce (http://www.perforce.com/) и rational clearcase (http://www.rational.com/). В конце статьи приведена ссылка на каталог, содержащий ссылки на большое количество систем управления версиями.

В настоящий момент активно ведется разработка того, что когда-нибудь придет на смену cvs: http://subversion.tigris.org/. Этот проект, subversion, разрабатывается с учетом положительных сторон cvs, у него новое, не страдающее от "старческих болезней", дерево исходников, некоторые из его разработчиков в прошлом участвовали в разработке cvs. Конечно же, subversion будет распространяться с исходными текстами и по свободной лицензии. Я очень надеюсь, что этому проекту будет сопутствовать успех! Но в любом случае cvs будет использоваться еще очень и очень долго.

Ссылки на дополнительную информацию

Домашняя страница cvs: http://www.cvshome.org/

Основной ресурс по cvs на open directory:
http://dmoz.org/computers/software/configuration_management/tools/concurrent_versions_system/

Крупнейший ресурс по cvs на русском языке (документация, статьи, список рассылки):
http://alexm.here.ru/cvs-ru/

Графический (а также обычный текстовый) cvs-клиент под win32:
http://www.cvsgui.org/

cvs-сервер под win32:
http://www.cvsnt.org/

Ссылки на другие системы управления версиями:
http://dmoz.org/computers/software/configuration_management/tools/
--------------------------------------------------------------------------------
Альтернативная версия данной статьи была опубликована в журнале "Программист", номер 2 за 2001 год, а авторский оригинал находится по адресу http://www.vak.ru/tcpip/internet.html.