CVS (Concurrent Versions System) является системой контроля версий: она хранит историю изменений определенного набора файлов, как правило программного обеспечения, и позволяет нескольким (порой весьма удаленным друг от друга) разработчикам совместно работать над одним проектом. CVS популярна в мире открытого ПО. Система разрабатывается по лицензии GNU General Public License.
Краткую флеш-презентацию введение в CVS (какие проблемы он решает, каковы основные понятия, достоинства и недостатки, и т.п.) можно просмотреть здесь.
CVS использует архитектуру клиент-сервер: сервер хранит текущую версию (версии) проекта и историю изменений, а клиент соединяется с ним, чтобы получить рабочую копию (данная процедура называется check-out), затем проделать необходимые изменения и позже залить эти изменения (check-in). Обычно клиент и сервер соединяются через локальную сеть или через Интернет, но могут работать и на одной машине, если необходимо вести историю версий локального проекта. CVS есть во всех популярных операционных системах.
Несколько клиентов могут работать над копиями проекта одновременно. Когда они отправляют результаты, сервер пытается слить их изменения в репозитории вместе. Если это не удается, например, в случае, когда два клиента изменили одни и те же строки в определенном файле, сервер не примет изменения от последней check-in операции и сообщит клиенту о конфликте, который должен быть исправлен вручную. Если check-in операция завершилась успешно, то номера версий всех затронутых файлов автоматически увеличиваются, и сервер записывает комментарий, дату и имя пользователя в свой журнал.
Клиенты также могут сравнить различные версии файлов, запросить полную историю изменений или получить исторический образ проекта на определенное число или по номеру ревизии.
CVS также может содержать различные ветки проекта. Например, стабильная версия проекта может составлять одну ветвь (branch), в которую вносятся только исправления ошибок, тогда как активная разработка может вестись в параллельной ветке, которая включает значительные улучшения или изменения с момента выхода стабильной версии.
CVS использует механизм delta compression для эффективного хранения различных версий одного и того же файла.
Содержание
Терминология
Проекты в CVS хранятся в виде модулей. Модуль — это набор файлов проекта. Сервер CVS может обслуживать несколько модулей; все модули хранятся в репозитории. Локальная копия модуля, полученная с помощью CVS клиента, называется рабочей копией.
История и статус
CVS является развитием более ранней системы контроля версий, имеющей название Revision Control System (RCS), которая все еще используется для работы с отдельными файлами но не цельными проектами.
На сегодняшний день код CVS содержит группа добровольцев. Интересен тот факт, что версия CVS для Microsoft Windows, отделившаяся в отдельный проект CVSNT, сейчас достаточно активно расширяет возможности системы даже портируя изменения обратно на UNIX под именем CVSNT.
Инструменты
Веб-интерфейсы
GUI-интерфейсы
Документация по CVS
Тесты
Можете проверить свои знания CVS интерактивной системой тестирования:
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
Система контроля версий позволяет вести конкурентную работу с набором текстовых файлов.
К файлам из Репозитория, возможен доступ только через интерфейс системы CVS:
При этом системой обеспечивается хранение всех версий файла, регистрация изменений от лица конкретного пользователя с точностью до строки, а также отслеживание возникших конфликтов.
CVS эффективно работает с текстовыми файлами, позволяя делать построчное сравнение версий, может также использоваться для хранения двоичных файлов, но, естественно, без сервиса по сравнению версий. Кроме того, если текстовые файлы хранятся довольно эффективно, то есть, фактически, имеется одна версия и журнал изменений, то двоичный файл при каждой правке запоминается целиком.
После получения последней версии файлов проекта с сервера большая часть работы сводится к следующим основным действиям:
Помимо простейшего цикла работы у CVS есть множество дополнительных возможностей.
Основной цикл работы с CVS
Под основным циклом работы понимается использование стандартных команд CVS, позволяющих читать файлы, изменять их и записывать изменения.
Каждый CVS-модуль (полное дерево каталогов), помещенный под контроль CVS, хранится в центральном репозитарии. Вся работа выполняется с локальной копией CVS-модуля изменения из которой переносятся в репозитарий по готовности. Для этого используется несколько основных команд.
checkout
Для создания локальной копии CVS-проекта необходимо выбрать каталог для проектов на локальном диске (напр. D:\projects), в котором будет создан подкаталог данного проекта. В этом каталоге выполнить команду
После этого в каталоге D:\projects\имя_проекта появляется локальная копия всего дерева последней версии указанного проекта.
Возможные значения параметра имя_проекта можно увидеть простым просмотром файла CVSROOT/modules, который можно запросить командой:
commit
После того, как проверено, что внесенные Вами изменения оставили проект в рабочем (по крайней мере, в компилируемом) состоянии, следует закрепить изменения в репозитарии. В принципе, можно использовать разную политику закрепления изменений (как можно чаще, как можно реже, только после успешной компиляции и т. д.). Выбор конкретной политики не влияет на работу самого CVS и обусловлен требованиями проекта. Закрепление изменений производится командой:
либо не указывая имя файла, что закрепляет все изменения в выбранной директории. Если не указан комментарий, то CVS запускает редактор для ввода пояснений в журнал версий.
Возможно, что изменения вносились в старую версию файла и с тех пор файл был поправлен. Об этом cvs commit выдаст сообщение:
и надо будет выполнить cvs update для конфликтного файла, а затем, возможно, разрешить конфликт (процедура описана ниже). Если одновременно закрепляются изменения в нескольких файлах, то если конфликт был в одном из них, то все закрепление сделано не будет.
update
Синхронизация с репозитарием может быть выполнена в любой момент командой
Ключ -d используется для проноса новых директорий, появившихся в проекте. Ключ -P удаляет пустые директории.
Данная команда является одной из самых безопасных, так как ничего не меняет на сервере. Отметим также, что если файл на локальном компьютере был испорчен по каким-либо причинам, например неверно отредактирован, то его можно восстановить удалив его на локальной машине и заново считав с сервера командой cvs update [file].
При работе команда cvs update выдает протокол действий в виде списка имен файлов, предваряемых одной буквой — статусом файла. Значения букв:
Проект может содержать директории, которые образованы специальным образом ссылкой на директории со стандартными файлами. Команда cvs update не копирует такие директории в вашу локальную копию проекта. Такие директории копируются командой
то есть той же командой, которая используется для создании копии проекта.
Если в директории завести файл с именем .cvsignore и поместить в него список шаблонов файлов, которые не должны помещаться под CVS, то на них «?» выдаваться не будет.
Если было внесено много исправлений и команда выдала большой список, ее можно запустить повторно — она выдаст только файлы с модификациями и конфликтами. Конфликт означает, что правки файла, сделанные пользователем локально конфликтуют с правками, внесенными в репозитарий кем-то еще. Соответствующие места в файле будут помечены:
Перед закреплением изменений необходимо эти конфликты разрешить.
Добавление директории или файла выполняется командой
Для файла необходимо затем выполнить cvs commit.
Под CVS можно хранить также бинарные файлы, хотя и не так эффективно, как текстовые, т. к. в этом случае, CVS будет полностью хранить каждую версию файла. Бинарные файлы добавляются с опцией «-kb»:
remove
Для удаления файла выполняются команды:
release
Если вдруг возникла необходимость убрать файлы из локальной CVS директории, то необходимо делать это командой:
в основном каталоге проекта. При этом производится проверка соответствия локальной директории и состояния репозитария. Если есть конфликтующие или расходящиеся файлы, то будет выдана диагностика о их наличии. Все расхождения нужно проанализировать и устранить. После этого необходимо повторно выполнить ту же команду, проверить, что измененных файлов нет, и ответить на задаваемый вопрос «Y». После этого все файлы проекта будут удалены.
Правила работы с CVS
При использовании CVS нужно придерживаться нижеописанных правил:
Расширенные возможности CVS
Рассмотрим функции и команды CVS, хотя и относительно редко используемые, но полезные во многих специальных случаях.
Для того, чтобы получить историю работы с файлом, нужно использовать команду
Результат работы рекомендуется перенаправлять в отдельный файл, который потом смотреть в произвольной кодировке. Выдается история изменений данного файла с номерами версий и пользователями, которые закрепляли данные версии.
update
Для того, чтобы получить конкретную версию файла, необходимо набрать команду
Из репозитария будет загружена версия с данным номером. Если в файле на локальном компьютере производились изменения, то они будут слиты с версией с запрашиваемым номером, что может привести к странным результатам и, обычно, после этого требуется устранить конфликт.
липкие метки
Локальный файл, который был получен путем считывания предыдущей версии считается замороженным (имеющим «sticky tag») и изменения в нем не будут закрепляться в репозитарии. Проверить наличие этого тага можно путем вызова команды для получения статуса файла
В результате исполнения выдается полная информация о версиях данного файла.
Для того, чтобы вернуться к последней версии файла, необходимо набрать команду
Команда обеспечивает снятие всех «sticky tag» с выбранного файла, она также синхронизирует файл с последней версией с сервера. Если мы вдруг произвели изменения в файле с установленным «sticky tag», то изменения не будут потеряны — они будут пронесены в последнюю версию файла, при этом естественно возникнет конфликт.
Для просмотра изменений файла от версии к версии нужно вызвать команду
Вторую версию можно не указывать, тогда будет взят текущий файл. Результат следует перенаправлять в отдельный файл. В файле будет приведен список отличий между версиями.
annotate
Для того, чтобы посмотреть, кто что написал в файле, необходимо использовать команду
Результат надо направлять в файл. В результате, для каждой строки исходного файла будет выведено имя пользователя и версия, в которой появилась данная строка.
Управление ветками под CVS
Для поддержки нескольких версий описаний библиотек, либо стандартов на разработку, необходимо использовать наиболее сложные возможности CVS — систему веток.
Путь развития каждого файла под CVS может представлять собой дерево (вообще говоря, даже многопотоковый граф). От основного ствола — основного пути изменения файла можно отщепить произвольное количество веток. На определенном этапе развития ветки могут быть снова слиты в одну ветку.
Для отщепления ветки используется механизм пометки тагами. Версия файла может быть помечена произвольным количеством тагов, таг — строка произвольного вида. Для данного файла существует одна и только одна версия помеченная конкретным тагом. Если мы хотим пометить тагом другую версию, то мы должны снять этот таг с предыдущей версии.
Для проекта таги используются для пометки определенных срезов информации. Эти срезы могут перемещаться и изменяться со временем.
Помимо обычных тагов бывают таги веток. Если мы хотим завести новую ветку у файла, то мы обязаны пометить ее веточным тагом. Отметим, что при поиске файла с тагом неважно, ищем мы файл по веточному тагу, либо по обычному.
Когда ветка выделена — она продолжает развиваться независимо, при этом последняя версия файла ветки помечена тагом этой ветки.
Для пометки файла тагом нужно использовать команду
Она пометит все файлы в директории и поддиректориях указанным тагом. Использование -F позволяет сдвигать таг, если он раньше был установлен.
Для того, чтобы создать ветку, нужно вызвать нижеследующие команды. Сначала нужно считать версию файла помеченную данным тагом — для проверки.
Далее следует проверить таг и признак тага — может быть ветка уже была создана. Также нужно проверить номер версии файла — отсюда ли мы хотим делать ветку. Вызвав команду
произведем проверку. Если мы хотим делать ветку из другого места, то мы должны считать нужную версию файла и сделать веткой при помощи команды
Команда создает ветку этого файла для стандарта с данным номером. Опция -F означает, что старый таг с этим именем будет удален.
Для того, чтобы считать ветку файла, необходимо вызвать команду
При этом на локальную машину будет помещены файлы из этой ветки, а за отсутствием файла в этой ветке — из основного ствола.
После этого локальная машина начинает работать с данной веткой. Команда update будут считывать более новые файлы этой ветки.
Для взятия последней версии основного ствола нужно использовать команду
Администрирование репозитария
Под администрированием репозитария понимается действия по созданию, удалению и импорту репозитария и отдельных CVS-модулей.
path место CVS-модуля внутри репозитория, например, для модулей документации — docs/projects/имя_проекта; vendortag создатель модуля. ;releasetag: идентификатор, определяющий версию проекта. Идентификатор должен начинаться с буквы и не должен содержать символов @,$,-.
Пример такой команды
Тесты
Можете проверить свои знания CVS интерактивной системой тестирования:
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
Автор: Илья Рыженков The RSDN Group Источник: RSDN Magazine #3
Опубликовано: 11.04.2003 Исправлено: 10.12.2016 Версия текста: 1.0.1
Введение
Необходимость управления исходными текстами
Управление исходными текстами является маленькой частью большой и сложной науки управления созданием программного обеспечения. Тем не менее, это одна из важнейших частей с точки зрения автоматизации, поскольку маленький и, в общем, несложный механизм обеспечивает информацией множество других частей общего бизнес-процесса. Управление исходными текстами имеет несколько аспектов: управление версиями, автоматическая генерация документации, поддержка единого стиля кода и контролируемые изменения. Постепенно мы раскроем все эти темы, но начнём, пожалуй, с наиболее востребованной части – управлением версиями. В этих статьях мы не будем подробно рассматривать общий подход к управлению разработкой, заинтересованных отсылаем к другим ресурсам (см. ссылки в конце статьи), однако на некоторых важных аспектах мне бы хотелось остановиться прежде, чем перейти собственно к рассмотрению темы данной статьи.
Существует множество различных точек зрения на то, каким должен быть процесс разработки программного обеспечения. Одни желают формального, тяжелого, гарантированного процесса, другим больше по душе легковесный, мобильный, рискованный процесс. Всё зависит от потребностей заказчика, компании, проекта и команды. Тем не менее, так или иначе, команда программистов создаёт код, который развивается и меняется со временем. В связи с этим можно отметить несколько фактов:
Таким образом, необходим инструмент, позволяющий централизованно хранить, получать и обновлять исходные тексты, отслеживать историю, получать версию кода по некоторым критериям и выполнять некоторые автоматические операции с кодом. Одним из таких инструментов является Concurrent Versions System (CVS).
Другие системы
Существует множество других систем для управления версиями, среди которых можно упомянуть Microsoft Visual SourceSafe, StarBase’s StarTeam и Rational ClearCase. В задачи данной статьи не входит ни сравнительный анализ этих систем, ни описание уникальных возможностей и недостатков. Если вы уже знакомы с какой-либо из систем управления версиями, постарайтесь не искать аналогий и способов сделать знакомые операции в новой среде. CVS отличается от этих систем в первую очередь концепцией использования в распределенных условиях.
Структура статьи
Если вам интересны лишь общие концепции и понимание системы как таковой – достаточно прочитать раздел «Основные понятия» и не тратить время на детали использования. В этом разделе объясняются принципы назначения версий, связь репозитория и рабочих каталогов, общий взгляд на автоматизацию процессов, а также кратко рассказано о связи 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 не навязывает никакой конкретной модели разработки. Команда может работать в том режиме, который диктуется требованиями клиента, политикой компании или взаимными договорённостями участников.
Cederqvist
Главным документом любого пользователя 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), которые подробно обсуждаются во второй части статьи при описании работы с редакциями и в третьей части при описании управления ветвями.
Репозиторий
ПРЕДУПРЕЖДЕНИЕ
Рабочий каталог – не то же самое, что репозиторий, и он не может быть подкаталогом репозитория. И наоборот, репозиторий не может находиться в подкаталоге рабочего каталога. В противном случае последствия непредсказуемы.
Рисунок 3.
Например, если ваш репозиторий находится на локальном или сетевом диске, вы можете использовать метод доступа local. Тогда CVSROOT будет выглядеть так (для Windows):
Обратите внимание, что для Windows слэши всё равно должны быть прямыми, а не обратными, как это принято в самой операционной системе. Кроме того, в CVS имена файлов чувствительны к регистру символов (case sensitive), тогда как Windows игнорирует регистр. Это может привести к проблемам, если у вас в репозитории находятся файлы File.h и file.h. Старайтесь использовать нижний регистр для имен файлов при работе с Windows.
Примеры CVSROOT с комментариями:
Совмещение и обновление
CVS всегда помнит, какие редакции у вас находятся в рабочем каталоге. Для изменённых файлов он помнит, какие редакции у них были до того, как вы начали изменять эти файлы. Это необходимо, чтобы правильно совместить несколько изменений, произошедших с файлом одновременно.
Предположим, что два разработчика одновременно начали работать над одним и тем же файлом, и в момент начала этого процесса в репозитории была редакция 1.1. По истечении определенного времени мы имеем в репозитории редакцию 1.1 и в двух рабочих каталогах изменения к этой редакции. Предположим также, что работа в каталоге №2 закончена и изменения отправляются в репозиторий (детали этой операции мы рассмотрим в следующей части статьи). В репозитории появляется новая редакция файла и ей присваивается номер 1.2. В каталоге №2 тоже содержится редакция 1.2. Однако в каталоге №1 по-прежнему находятся изменения относительно редакции 1.1.
Рисунок 4.
Теперь, если мы захотим отправить изменения в репозиторий из рабочего каталога №1, система откажет нам в операции, поскольку каталог №1 устарел и сформировать редакцию 1.3 в репозитории невозможно. Поэтому каталог №1 необходимо сначала обновить, при этом произойдёт совмещение (merge) редакций. Иными словами, изменения от 1.1 до 1.2, имеющиеся в репозитории, будут применены к файлу в рабочем каталоге. При этом изменения, сделанные локально, не пропадают и, в результате, в рабочем каталоге оказывается редакция 1.2 с изменениями, сделанными локально. Теперь можно спокойно отправить файл в репозиторий и получить редакцию 1.3, в которой наличествуют изменения, сделанные в обоих рабочих каталогах. Для полного завершения картины мы должны обновить каталог №2 (там по-прежнему находится редакция 1.2) до редакции 1.3, имеющейся в репозитории.
Всё ли так гладко и замечательно, как кажется на первый взгляд? В большинстве случаев – да. Однако существуют моменты, когда в процессе совмещения редакций возникает ситуация, при которой CVS не может самостоятельно решить вопрос о слиянии. Например, если в предыдущем примере в обоих рабочих каталогах был исправлена одна и та же строчка, но по-разному. Вообще говоря, для CVS важно, чтобы изменения были достаточно далеко друг от друга. Тогда процесс совмещения происходит автоматически. Если же изменения слишком близки, возникает конфликт, который необходимо разрешить вручную прежде, чем продолжать работу. Более подробно о конфликтах рассказывается в пункте «Разрешение конфликтов» второй части статьи.
Базовые операции
Подготовка к работе
Установка
Исполнение команд
Общий синтаксис операций с CVS выглядит так:
Угловой скобкой в начале строки «>» я буду отмечать текст, набираемый в командной строке. Текст без угловой скобки, следующий за командой, является предполагаемым выводом.
Иными словами, после имени исполняемого модуля идут опции, общие для всех команд и определяющие функционирование системы в целом, а после имени команды – опции, определяющие поведение этой команды, и специфичные для команды аргументы. Ниже приводится список ключей для CVS.
ПРЕДУПРЕЖДЕНИЕ
Некоторые ключи имеют одинаковое наименование, но совершенно разный смысл, когда используются как ключи к CVS (cvs –key command) и как ключи к команде (cvs command –key). Будьте внимательны при использовании ключей и располагайте их в правильном месте.
WINCVS Можно использовать Admin\Command line… для выполнения команд CVS, набранных вручную.
Создание репозитория
Эксперименты проще всего производить с локальным репозиторием. Работа с удаленным CVS мало чем отличается, однако в этом случае Вам должен быть известен правильный CVSROOT. Например, администратор CVS-сервера может создать тестовый репозиторий и сообщить Вам необходимую информацию. Для работы с локальным репозиторием необходимо его проинициализировать самостоятельно. Создайте где-либо пустой каталог и выполните команду инициализации:
Ключ –d позволяет задать CVSROOT в командной строке. Команда init проводит первичную инициализацию репозитория. Вы можете создать сколько угодно репозиториев в разных, не пересекающихся каталогах и использовать их для различных категорий проектов, разных команд, как приватный и публичный и так далее.
В созданном пустом каталоге должен появиться подкаталог «CVSROOT», содержащий некоторое количество управляющих файлов. В этой статье устройство репозитория рассматриваться не будет.
WINCVS Локальный репозиторий создается командой «Create\Create a new repository… «.
Создание проекта
Прежде чем помещать проект под управление CVS, следует тщательно продумать конфигурацию проекта, именование файлов и структуру каталогов. Особенно это важно в отношении каталогов. В связи с тем, что CVS должен хранить редакции всех, даже удалённых файлов, каталоги никогда не удаляются. Поэтому переименование каталогов и перемещение файлов могут вызвать трудности.
СОВЕТ
Если используется Windows – давайте всем файлам имена в нижнем регистре.
Начните с проекта, состоящего из одного текстового файла. В пустом каталоге с именем “test” создайте файл “readme.txt” следующего содержания:
Теперь необходимо поместить файл в репозиторий:
Выполнять эту команду следует из корневого каталога проекта, в этом примере – из каталога “test”.
В нашем случае эта команда может выглядеть так:
Вывод команды означает, что в репозитории был создан файл для хранения редакций readme.txt в каталоге test, и не произошло никаких неприятностей в процессе работы.
WINCVS Выберите пункт меню » Create\Import module… » Затем выберите каталог, который вы хотите импортировать в репозиторий. Далее появится список типов файлов, обнаруженных в каталоге. Вы можете выбрать, какие из них необходимо импортировать, а какие нет.
Теперь, если краешком глаза заглянуть в репозиторий, можно обнаружить там новый каталог с именем test, внутри которого CVS расположил свои служебные файлы и файлы проекта с информацией о редакциях – проект создан и находится в репозитории. Однако локальный каталог до сих пор не имеет никакого отношения к CVS – файлы всего лишь «скопированы» в репозиторий. Теперь нужно создать структуру, которая бы хранила информацию о связи с репозиторием локально.
ПРЕДУПРЕЖДЕНИЕ
Импорт файлов в репозиторий не создаёт локальной структуры с информацией о связи с репозиторием
Чтобы создать связь между репозиторием и рабочим каталогом, необходимо выполнить другую операцию – checkout. Но предварительно нужно. удалить каталог, из которого импортировались файлы. Он больше не нужен, поскольку вся необходимая информация содержится в репозитории. Возможно, неплохой мыслью будет резервное копирование проекта, но в данном случае этого можно не делать. Итак, удалите каталог “test”, из которого производился импорт. Теперь можно произвести операцию получения рабочей копии из репозитория.
Получение рабочей копии
Скорее всего, у Вас есть некоторый каталог, где и хранятся разнообразные проекты. Это хороший кандидат для использования в качестве основного каталога для получения рабочих копий проектов из CVS. Предположим для простоты, что это c:\projects\
WINCVS Хорошей мыслью может быть установка этого каталога в качестве корневого для дерева каталогов. Используйте » View\Browse Location\Change… «, чтобы установить его. Это избавит Вас от лишней информации во время работы с WinCVS
Установите этот каталог в качестве текущего:
Далее необходимо выполнить команду checkout, которая получит рабочую копию файлов из репозитория и правильно настроит все служебные файлы.
Вывод команды показывает, что произошло обновление файла readme.txt из репозитория. Буква «U» означает, что файл был получен полностью (updated). Теперь у Вас должен был появиться каталог test, в котором находятся ранее импортированный readme.txt и каталог «CVS», содержащий служебную информацию. Обычно там будут находиться 3 файла с именами Entries, Repository и Root. В файле Entries CVS сохраняет информацию о файлах, которыми он управляет, их редакциях и датах обновления. В файле Repository хранится путь к данному каталогу в репозитории относительно CVSROOT. Сам CVSROOT сохраняется в файле Root. Именно потому, что для каждого каталога известен cvsroot и местоположение в репозитории, при работе с проектом указывать их (с помощью ключа –d) нет необходимости. С этого момента у Вас имеется рабочий каталог, связанный с репозиторием. Вся необходимая служебная информация находится в каталогах CVS, которые будут созданы также в каждом подкаталоге, если таковые появятся впоследствии.
Эту же операцию должны проделать и другие участники проекта, если они есть. Заметьте, что команда import выполняется одним человеком и создаёт структуру данных в репозитории. Все участники проекта должны проделать только операцию checkout и сразу получить связанный с репозиторием рабочий каталог.
Изменение рабочей копии
Согласитесь, создать проект было не так-то просто, с учётом всех премудростей. Зато с этого момента наступает просто благодать! Никаких специальных действий для редактирования рабочих файлов предпринимать не нужно. Вы просто вносите все необходимые изменения до тех пор, пока результат вас не устроит. По завершении работы результаты отправляются в репозиторий командой commit (см. Отправка изменений в репозиторий). А пока давайте внесем изменения в файл readme.txt, например, удалим последнюю строчку и вставим новую. После изменений readme.txt может выглядеть так:
В некоторых случаях всё-таки придётся совершить определённые действия, прежде чем обновлять центральное хранилище. Речь идёт о появлении новых файлов и каталогов, которые пока еще отсутствуют в репозитории. Предлагаю сразу создать новый файл с именем todo.txt:
Теперь надо сообщить системе управления версиями о появлении нового файла. Для этого используется команда add, которая выполняется из того же каталога, в котором находится новый файл
Файл todo.txt теперь помечен на добавление, но реально он будет помещен в репозиторий при выполнении команды commit, о чём и напоминает вывод этой команды. Вы также можете добавить ключ –m “comment” для указания комментария для добавленного файла. В отличие от многих других команд, в отсутствие ключа –m не будет открыт редактор для ввода комментария, вместо этого комментарий будет считаться пустым.
Аналогичным образом производится удаление файла – используется команда remove. Команда remove требует отсутствия файла в рабочем каталоге, то есть вы должны сначала удалить файл физически, иначе CVS откажется удалять его из репозитория:
Вы можете удалить файл самостоятельно:
Или попросить сделать это CVS, используя ключ –f для команды remove
Если же после удаления файла вы передумали и решили всё-таки не удалять его, выполнение команды add воскресит файл:
Помните, команды add и remove не производят операций с репозиторием (за исключением воскрешения файла), они только помечают их для выполнения операции во время отправки изменений в репозиторий.
Отправка изменений в репозиторий
После изменения исходных текстов в локальном каталоге необходимо отправить изменения в репозиторий. Изменения для каждого файла обрабатываются отдельно, поэтому редакция файла изменится только в том случае, если его содержимое отличается от того, что хранится в репозитории. Для сохранения результатов работы в репозитории используется команда commit. Давайте подробно рассмотрим, что происходит при выполнении этой команды:
Ключ –m “comment” задаёт комментарий к изменениям, чтобы впоследствии можно было легко определить, чем именно данная редакция отличается от предыдущей. Поскольку в любой момент можно посмотреть различие в тексте между любыми редакциями, нет смысла указывать, какие строчки добавлены или изменены. Цель комментария – описание результатов работы в целом, а не конкретных изменений. Комментарии являются очень важной частью работы команды, поскольку позволяют другим разработчиком узнать, что именно вы сделали, и скоординировать свою работу соответственно. Если кому-то интересны детали вашей работы, он может заглянуть в код, сравнить редакции и разобраться во внесенных изменениях. В конце концов, он может спросить Вас лично.
ПРЕДУПРЕЖДЕНИЕ
CVS не заменяет управления, общения и других процессов, которые должны происходить при совместной разработке программного продукта несколькими участниками. CVS предназначен для отслеживания редакций исходных текстов и централизованного хранения проектных файлов.
Получив команду commit, CVS начинает изучение рабочего каталога. Пользуясь информацией, сохранённой в каталогах с именами «CVS», он определяет, какие файлы были изменены и выполняет для каждого операцию обновления. Для этого он получает из репозитория редакцию файла, находившуюся в рабочем каталоге до изменений, и сравнивает содержимое. При наличии изменений CVS создаёт в репозитории новую редакцию для этого файла, в которую внесены соответствующие поправки. Операция выполняется рекурсивно для всех подкаталогов.
WINCVS Чтобы отправить файлы в репозиторий, используйте команду Commit из меню Modify
В нашем примере изменился файл readme.txt и добавился файл todo.txt. После выполнения команды commit в репозитории создаётся новый файл для отслеживания редакций файла todo.txt, и текущему его содержимому присваивается номер 1.1. Измененному содержимому файла readme.txt присваивается номер 1.2. Мы по-прежнему можем получить редакцию 1.1 файла readme.txt, если нам это потребуется, но об этом я расскажу чуть позже.
Обновление рабочей копии
Если вы – не единственный участник проекта, и одним репозиторием пользуются одновременно несколько человек, то любой из них мог обновить репозиторий. В этом случае для работы с самыми свежими исходными текстами необходимо периодически выполнять операцию обновления рабочего каталога из репозитория. Процесс этот во многом симметричен процессу отправки изменений в репозиторий, хотя имеются и различия. Вы выполняете команду update, и изменения, произошедшие в репозитории, отражаются в рабочих файлах. Однако для того, чтобы посмотреть этот процесс в действии, понадобится еще один рабочий каталог. Чтобы его создать, воспользуйтесь командой checkout с ключом –d из каталога проектов (например, c:\projects):
Обратите внимание, что ключи –d до и после команды checkout имеют разный смысл. Первый указывает на местонахождение репозитория, а второй указывает, что файлы нужно получить в каталог test2, а не test
После выполнения этой команды будет создан второй рабочий каталог, связанный с тем же репозиторием и теми же файлами в нём. Таким образом, можно внести изменения в одном рабочем каталоге и получить их в другом, некоторым образом эмулируя работу нескольких программистов. Итак, измените в новом рабочем каталоге файл todo.txt (я добавил строчку «Some change» в конец файла) и выполните операцию commit для обновления репозитория:
Команда cvs status показывает текущее состояние каталога – сообщает, необходимо ли обновление, какие редакции у локальных файлов и прочую полезную информацию.
В репозитории создана новая редакция, однако в рабочем каталоге «test» еще нет информации об этом обновлении. Необходимо выполнить update в этом каталоге, чтобы получить изменения из репозитория. Выполните команду update из каталога «test»:
В процессе выполнения команды система изучила содержимое репозитория и рабочего каталога, и обнаружила, что файл todo.txt в репозитории изменился, поэтому он и был обновлён. Буква «U» перед именем файла является сокращением от Update и означает, что файл был обновлен из репозитория целиком, поскольку локальных изменений в нём не было. Что же произойдёт, если перед выполнением команды update изменить файл в рабочем каталоге «test»? Возникнет ситуация, когда требуется совмещение редакций:
В этом случае CVS сначала получает из репозитория изменения к текущей редакции (1.2) относительно исходной локальной редакции (1.1, так как она выглядит в репозитории). Затем CVS совмещает изменения от 1.1 до 1.2 и от 1.1 до текущей локальной копии файла. В результате этих непростых вычислений получается локальный файл, содержащий локальные изменения уже относительно версии 1.2.
Буква «М» перед именем файла указывает, что файл был изменен локально, и операция commit еще не проводилась. Иными словами, в рабочем каталоге присутствуют изменения, которых нет в репозитории.
WINCVS Алгоритм, реализующий данную функциональность, довольно сложен, и описание его выходит за рамки этой статьи. Интересующиеся могут поискать информацию по ключевым словам CVS, RCS, diff3, merge.
Обычно CVS в состоянии самостоятельно совместить изменения, однако в случае пересечения изменений или их слишком близкого расположения CVS отказывается совмещать их сам, информирует о конфликте и оставляет рабочий файл в специальном формате. После этого необходимо разрешить конфликт вручную.
Разрешение конфликтов
Конфликт может возникнуть при совмещении двух изменений, если они пересекаются или расположены слишком близко друг к другу. Поскольку совмещение (merge) возникает при изменении текста и в репозитории, и в рабочем каталоге, вы не получите конфликта, если не меняете файлов локально (например, просто скачиваете обновления из общедоступного репозитория в Интернете). Вы также не получите конфликта, если никто кроме вас не производит обновления репозитория, например, при использовании CVS лично для себя в домашних условиях. Если же вы работаете в команде, которая активно развивает исходный текст – рано или поздно конфликт неизбежен.
При возникновении конфликта вывод CVS выглядит аналогично нижеследующему.
Буква C помечает файл, в котором был обнаружен конфликт. При указании ключа –q или –Q сообщений о конфликтах будет меньше, но сути это не меняет.
WINCVS CVS разработан так, чтобы никогда не терять изменений. Поэтому во многих случаях он сохраняет резервные копии в файлах с именами начинающимися с «.#» (точка, решётка). В общем случае имя файла выглядит так: «.#исходное-имя-файла.номер.редакции», например «.#test.c.1.1». Например, эти файлы сохранят измененные версии на случай ошибочного разрешения конфликта.
Внутри файла, в котором обнаружен конфликт, проблемные участки текста будут заключены в своеобразные скобки:
Внутри зоны конфликта также будет находиться разделитель «=======», который отделяет ваше изменение от проблемного, полученного из репозитория. Полностью маркировка конфликта выглядит так:
Теперь можно разрешить конфликт и оставить код в том состоянии, которое считаете правильным. При необходимости, можно пообщаться с автором конфликтующего изменения и разрешить этот вопрос совместно.
ПРЕДУПРЕЖДЕНИЕ
CVS считает, что если время модификации файла (modification time) изменилось с момента обнаружения конфликта, то проблема решена и файл готов к отправке в репозиторий. Поэтому сначала рекомендуется просмотреть все конфликты в файле (их может быть несколько) используя, например, поиск строки “ cvs update и получает сообщение о конфликте. Открыв файл, он обнаруживает следующее:
Разрешение конфликта не займёт много времени, и файл вновь принимает рабочий вид.
После этого можно выполнить операцию commit
Работа с редакциями
Управление редакциями может показаться довольно запутанным процессом, если не разобраться как следует в том, как CVS управляет ими в репозитории. Кратко сформулируем основные правила:
Установка символического имени для редакций
Вы можете установить метку ( tag ), объединяющую редакции файлов, находящихся в рабочем каталоге. Например, можно установить имя для всех файлов в текущем состоянии репозитория после выпуска очередной версии своего продукта на рынок. Для этого используется команда tag:
В отличие от команд add, remove и модификации файла, команда tag работает напрямую с репозиторием и присваивает метки редакциям файлов, которые находятся в настоящий момент в рабочем каталоге. Поскольку команда модифицирует репозиторий напрямую, она не принимает во внимание локальные изменения, которые Вы, возможно, внесли в файлы в рабочем каталоге. Можно заставить CVS проверить, что все файлы находятся в репозитории, добавив ключ –c к команде tag:
Получение конкретной редакции файла
Для того, чтобы получить какую-то конкретную редакцию файла, уже ставшую историей, достаточно задать дополнительные параметры для команды update или checkout. Но прежде, чем описать эти параметры, необходимо остановиться на продолжительности действия их результатов. Многие параметры сохраняют в рабочем каталоге так называемые липкие метки. Липкие метки сохраняют свое действие для всех последующих команд, даже если соответствующие параметры не указаны. Они необходимы, когда требуется ограничить обновление определённой части проекта. Например, в отдельном каталоге может находиться библиотека, разрабатываемая другой командой, и вас интересуют только её стабильные версии. Каждый раз, когда появляется следующая стабильная версия библиотеки, её разработчики создают новую метку, и вы обновляете рабочий каталог с указанием этой метки. Дальнейшие модификации не будут попадать в рабочий каталог до следующей стабильной версии.
Такие метки нужно сбрасывать явно, если их действие больше не требуется. Для их сброса используется ключ –A команды update
Такая команда сбросит все прилипшие метки и получит самую свежую копию из репозитория для всех файлов в текущем каталоге (рекурсивно для подкаталогов). Получить текущее состояние липких меток можно командой status.
Теперь рассмотрим команды, которые помогут получить самые различные редакции файлов.
Чтобы получить конкретную редакцию по номеру или метке для отдельного файла, подкаталога или всего проекта, используется ключ –r для команды update, параметром к которому должен быть либо номер редакции, либо ранее присвоенная метка. Следующая команда приведёт рабочий каталог к состоянию, в котором эта метка была присвоена:
А эта команда достанет из репозитория самую первую редакцию файла readme.txt – то состояние, в котором он был добавлен в репозиторий:
Параметр –r создаёт липкую метку для файлов. Если вы получили конкретную редакцию или набор файлов по метке, вы больше не будете получать обновлений, пока не сбросите липкие метки или кто-то их не передвинет.
ПРЕДУПРЕЖДЕНИЕ
Использование номера редакции при обновлении каталога относительно бессмысленно. Редакции файлов независимы, поэтому команда cvs update –r 1.2 достанет из репозитория все файлы, которые вообще хоть раз обновлялись, и именно их вторую редакцию. Скорее всего, это будет несовместная сборка файлов из разных периодов жизни проекта, в том числе и уже удалённых. Пользуйтесь символическими метками (тегами) для установления логической связи между редакциями файлов.
Ключ –D поможет получить состояние исходных текстов по дате создания редакции. Выбирается самая последняя редакция, созданная не позже указанной даты. Например, можно получить вчерашние файлы, если вчера всё работало, а сегодня что-то сломалось. Можно просто посмотреть какой-то старый код, в котором была нужная сегодня функция.
Такое обновление также создаёт липкие метки на файлах – пока они их не сброшены, Вы не получите обновлений с датой позже указанной. Формат даты ( date_spec) может быть очень разным, CVS поддерживает многое из спецификации ISO8601, но вам, скорее всего, понадобится всего несколько вариантов, которые я здесь приведу в качестве примера:
Заключение
В этой статье я попытался рассказать о базовых возможностях работы с CVS с тем, чтобы любой программист мог непосредственно начать использовать это мощное средство. Тем не менее, возможности CVS не ограничиваются описанными в этой статье. В следующей статье о CVS мы продолжим изучение этой системы.
