Управление исходными текстами. Часть 1. Краткое руководство по CVS
Шрифт:
Версии файлов
В большинстве случаев пользователи CVS не сталкиваются напрямую с нумерацией версий файлов, однако для общего понимания системы и выполнения некоторых операций необходимо понимать, что является версией файла, как они меняются и что означают. Вообще говоря, в CVS не принято использовать термин «версия». Вместо него используется термин «редакция». Делается это для того, чтобы избежать возможных конфликтов с версией продукта как целого (например, Microsoft Explorer версии 6), версией изменения (относится к управлению изменениями и в данной статье не обсуждается) и тому подобных проблем. Мы тоже будем придерживаться этой практики в нашей статье, и, хотя кое-где и будет употребляться слово
Что же такое редакция файла? В процессе работы над проектом файлы претерпевают изменения, добавляются новые и исчезают ненужные. Редакцией называется зафиксированное в репозитории (центральном хранилище файлов) состояние файла. Изменения файлов в рабочем каталоге не создают новых редакций, сколько бы дней или даже месяцев вы над ними не работали. Редакция появляется тогда, когда вы отправляете изменения в репозиторий. Самая первая редакция появляется при добавлении файла в репозиторий и получает номер 1.1. Вообще, в CVS все редакции имеют чётное количество десятичных чисел, разделённых точками. Более подробно формирование номера редакции мы рассмотрим позже, в части посвящённой ветвям, а пока будет считать, что это два десятичных числа, разделенных точкой. При создании новой редакции последнее число увеличивается на единицу:
Рисунок 2.
Кроме цифровых номеров редакций, которые для простоты можно рассматривать как внутренний механизм CVS, можно использовать и символические имена. Вы можете присвоить символическое имя отдельной редакции отдельного файла, группе файлов или всему проекту сразу. Для выполнения этой функции используются «метки» (tags), которые подробно обсуждаются во второй части статьи при описании работы с редакциями и в третьей части при описании управления ветвями.
Репозиторий
Как уже говорилось, в репозитории хранятся все файлы и каталоги, которые участвуют в проекте, все их редакции и даже уже удалённые файлы. Обычно при работе с CVS у Вас не будет прямого доступа к репозиторию. Вместо этого вы будете использовать cvs-команды для получения, обновления и других манипуляций с файлами, находящимися под управлением системы контроля версий. Каталог, в котором находятся рабочие файлы, называется рабочим каталогом.
ПРЕДУПРЕЖДЕНИЕ. Рабочий каталог – не то же самое, что репозиторий, и он не может быть подкаталогом репозитория. И наоборот, репозиторий не может находиться в подкаталоге рабочего каталога. В противном случае последствия непредсказуемы.
Чтобы указать системе, где находится репозиторий, необходимо указать его идентификатор (CVSROOT). Это строка, однозначно определяющая репозиторий, однако её формат зависит от того, как система получает доступ к репозиторию. Существуют разные методы доступа к репозиторию – локально, по сети, с разным уровнем защиты и по разным протоколам. Чтобы сообщить CVS, каким конкретно методом пользоваться, используется нотация метода доступа (access method notation). В общем виде CVSROOT выглядит следующим образом:
Рисунок 3.
Например, если ваш репозиторий находится на локальном или сетевом диске, вы можете использовать метод доступа local. Тогда CVSROOT будет выглядеть так (для Windows):
или так (для UNIX):
ПРЕДУПРЕЖДЕНИЕ. Обратите
Примеры 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, имеющейся в репозитории.