Читаем Управление исходными текстами. Часть 1. Краткое руководство по CVS онлайн бесплатно

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

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

• В коде исправляются старые и появляются новые ошибки, добавляются новые возможности и удаляются устаревшие участки кода, забывается то, что было в коде раньше - код нуждается в истории. Иначе невозможно установить, когда появилась проблема, какое изменение породило ошибку и кто, в конце-то концов, виноват.

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

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

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

Существует множество других систем для управления версиями, среди которых можно упомянуть Microsoft Visual SourceSafe, StarBase’s StarTeam и Rational ClearCase. В задачи данной статьи не входит ни сравнительный анализ этих систем, ни описание уникальных возможностей и недостатков. Если вы уже знакомы с какой-либо из систем управления версиями, постарайтесь не искать аналогий и способов сделать знакомые операции в новой среде. CVS отличается от этих систем в первую очередь концепцией использования в распределенных условиях.

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

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

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

Каждый разработчик имеет собственную копию всех исходных текстов проекта, с которыми он работает локально на своём компьютере. Разработчик вносит необходимые изменения в код, после чего помещает изменения с соответствующим комментарием в центральное хранилище, называемое репозиторием (repository). После этого остальные члены команды могут обновить свои локальные копии путем получения изменений из репозитория. Самое важное в этом процессе заключается в том, что изменения, внесенные в локальные копии, не замещаются, а совмещаются с изменениями в репозитории. Этот процесс называется merging и даёт право на слово Concurrent (одновременный) в названии инструмента. Действительно, несколько человек могут вносить изменения в одни и те же файлы одновременно и, тем не менее, не уничтожать результаты трудов друг друга.

Рисунок 1.

История CVS началась с нескольких скриптов, написанных Диком Грюном (Dick Grune) в декабре 1986 года. Хотя, пожалуй, ни строчки оригинального кода не сохранилось, довольно большая часть алгоритма разрешения конфликтов восходит к тому времени. В апреле 1989 Брайн Берлинер (Brian Berliner) придумал и разработал собственно CVS. Впоследствии ему помогал Джефф Полк (Jeff Polk) в развитии подсистем ветвей и модулей. В дальнейшем проект развивается как Open Source, его официальной web-страницей является http://www.cvshome.org.

CVS не является заменой управлению проектами, это всего лишь один из инструментов команды. Также этот инструмент сам по себе не содержит механизмов автоматический сборки (build system), регрессионного тестирования (regression testing), взаимодействия разработчиков (collaboration) и отслеживания ошибок (bug-tracking). Тем не менее, на базе CVS можно построить многие, если не все из этих механизмов, для получения полноценной среды разработки ПО.

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

Главным документом любого пользователя CVS является “Version Management with CVS”. Написанный Пэром Седерквистом (Per Cederqvist) и другими, он является «официальным» руководством де-факто. Документ, известный под кодовым именем «The Cederqvist», описывает работу с репозиторием, ветвями, файлами, резервное копирование, различные тонкости, а также содержит прочую полезную информацию. Документ доступен для скачивания с официальной страницы CVS. Перевод на русский язык доступен на странице Алексея Махоткина, автора перевода, по адресу http://alexm.here.ru/cvs-ru/cvs-ru.html

В большинстве случаев пользователи CVS не сталкиваются напрямую с нумерацией версий файлов, однако для общего понимания системы и выполнения некоторых операций необходимо понимать, что является версией файла, как они меняются и что означают. Вообще говоря, в CVS не принято использовать термин «версия». Вместо него используется термин «редакция». Делается это для того, чтобы избежать возможных конфликтов с версией продукта как целого (например, Microsoft Explorer версии 6), версией изменения (относится к управлению изменениями и в данной статье не обсуждается) и тому подобных проблем. Мы тоже будем придерживаться этой практики в нашей статье, и, хотя кое-где и будет употребляться слово «версия», она никогда не будет относиться к «редакциям» файлов.

Что же такое редакция файла? В процессе работы над проектом файлы претерпевают изменения, добавляются новые и исчезают ненужные. Редакцией называется зафиксированное в репозитории (центральном хранилище файлов) состояние файла. Изменения файлов в рабочем каталоге не создают новых редакций, сколько бы дней или даже месяцев вы над ними не работали. Редакция появляется тогда, когда вы отправляете изменения в репозиторий. Самая первая редакция появляется при добавлении файла в репозиторий и получает номер 1.1. Вообще, в CVS все редакции имеют чётное количество десятичных чисел, разделённых точками. Более подробно формирование номера редакции мы рассмотрим позже, в части посвящённой ветвям, а пока будет считать, что это два десятичных числа, разделенных точкой. При создании новой редакции последнее число увеличивается на единицу:

Рисунок 2.

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

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

ПРЕДУПРЕЖДЕНИЕ. Рабочий каталог – не то же самое, что репозиторий, и он не может быть подкаталогом репозитория. И наоборот, репозиторий не может находиться в подкаталоге рабочего каталога. В противном случае последствия непредсказуемы.

Чтобы указать системе, где находится репозиторий, необходимо указать его идентификатор (CVSROOT). Это строка, однозначно определяющая репозиторий, однако её формат зависит от того, как система получает доступ к репозиторию. Существуют разные методы доступа к репозиторию – локально, по сети, с разным уровнем защиты и по разным протоколам. Чтобы сообщить CVS, каким конкретно методом пользоваться, используется нотация метода доступа (access method notation). В общем виде CVSROOT выглядит следующим образом:

:метод-доступа:некоторые-данные-специфичные-для-метода

Рисунок 3.

Например, если ваш репозиторий находится на локальном или сетевом диске, вы можете использовать метод доступа local. Тогда CVSROOT будет выглядеть так (для Windows):

:local:c:/cvs/repository/

или так (для UNIX):

:local:/usr/local/cvsroot

ПРЕДУПРЕЖДЕНИЕ. Обратите внимание, что для Windows слэши всё равно должны быть прямыми, а не обратными, как это принято в самой операционной системе. Кроме того, в CVS имена файлов чувствительны к регистру символов (case sensitive), тогда как Windows игнорирует регистр. Это может привести к проблемам, если у вас в репозитории находятся файлы File.h и file.h. Старайтесь использовать нижний регистр для имен файлов при работе с Windows.

Примеры CVSROOT с комментариями:

:pserver:user@megasoft.com:/cvsroot

 Метод доступа pserver – простая авторизация паролем

 Сервер находится по адресу megasoft.com

 Имя пользователя “user”

 Локальный путь на сервере к репозиторию - /cvsroot

 Пользователь должен выполнить команду login перед доступом к серверу

:sspi:dev-server:/projects

 Метод доступа sspi – использование авторизации в Windows-домене

 Сервер – dev-server в текущем домене

 Имя пользователя – текущий пользователь Windows

 Условное имя репозитория на сервере – projects

:method:[[user][:password]@]hostname[:[port]]/path/to/repository

 Общий вид для удалённого репозитория

 Использовать открытый пароль в CVSROOT крайне не рекомендуется, лучше пользоваться командой cvs login