ИНДИВИДУАЛЬНОЕ ЗАДАНИЕ

Обзор возможностей 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 <stdio.h>

int main() {
  printf("hello world\n");
}
=== 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 <stdio.h>

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

	$ 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 <stdio.h>
	 
	 int main() {
	-  printf("hello world\n");
	+  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 конфликтов практически не возникает (я говорю на основании опыта двухмесячной работы трех программистов над одним проектом). За эти два месяца я наблюдал, ну может быть, три или четыре конфликта. Все они были простейшими и исправлялись за три минуты. Никаких проблем, связанных с совместной работой, замечено не было.

Материал на данную магистра Ильенко О. ссылка