Полезная информация

Server for Information Technologies Сервер поддерживается
Центром Информационных Технологий
(095) 932-9212, 932-9213, 939-0783
E-mail: info@citforum.ru
Сервер содержит море(!) аналитической информации CIT Forum CD-ROM

RCSINTRO(1)
КОМАНДЫ ПОЛЬЗОВАТЕЛЯ

НАЗВАНИЕ
обзор системы RCS - введение в Систему Отслеживания Версий

ОПИСАНИЕ
RCS (Revision Control System) представляет собой систему отслеживания версий изменяющихся текстовых или состоящих из строк двоичных файлов, как текст на русском языке ( о прочих -- см. флаг -kb команды co) файлов. RCS автоматизирует архивирование (не путать со сжатием!), востребование, регистрацию изменений, идентификацию и сравнение файлов, а также внесение изменений в документ, измененный другими за время вашей работы. RCS полезна для работы с часто изменяющимися документами, например, программами в процессе разработки, технической документацией, научными статьями, деловой перепиской, сборниками инструкций, и существенно облегчает работу с большими системами, в особенности, если изменения в документы вносят разные люди.

Взаимодействие с пользователем чрезвычайно просто. Новичку достаточно знать две команды: ci и co.

ci - сокращение от "check in" = "регистрация" (в том смысле, в каком понимается регистрация на самолет) - помещает содержимое рабочего файла в архивный файл, хранящий предыдущие его версии (точнее, изменения между версиями) и называемый также RCS-файлом.

co - сокращение от "check out" представляют собой не обратный процесс исключения, а получение копии некоторой версии из RCS-архива.

ФУНКЦИИ RCS

ПЕРВЫЕ ШАГИ В РАБОТЕ С RCS
Предположим, Вы хотите отслеживать с помощью RCS изменения файла f.c . Создайте в том каталоге, где находится файл f.c , подкаталог RCS ,

	mkdir  RCS
а затем зарегистрируйте его:
	ci  f.c

Эта команда создаст в подкаталоге RCS некий архивный файл ( RCS/f.c,v , если операционная система поддерживает запятые в имени файла, и RCS/f.c , если -- нет), поместит в него f.c в качестве версии 1.1 и запросит у вас описание файла -- что он из себя представляет, зачем нужен и т.п. Эта запись будет относиться ко всем версиям. При регистрации (внесении) последующих изменений RCS запрашивает сообщение другого сорта -- регистрационную запись -- описание внесенного изменения, которое будет относиться к данной конкретной версии. Эти записи и составят историю изменений файла.

В подкаталоге RCS находятся архивные или RCS-файлы, соответствующие находящимся уровнем выше рабочим файлам. Для того, чтобы восстановить файл f.c из предыдущего примера, используйте команду co :

	co  f.c

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

	co  -l  f.c
( -l -- "lock" = "запереть"). Теперь Вы можете редактировать f.c .

Предположим, по окончании редактирования Вы хотите оценить внесенные изменения. Команда

	rcsdiff  f.c

сообщит Вам изменения файла по сравнению с его последней зарегистрированной версией так же, как это делает команда diff(1). Занести новую версию в архив можно командой

	ci  f.c
что придаст новой версии очередной порядковый номер.

При регистрации возможно сообщение об ошибке:

	ci error: no lock set by your_name

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

	rcs  -l  f.c

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

Бронирование гарантирует, что никто, кроме Вас не сможет зарегистрировать следующую версию и, таким способом позволяет избежать проблем, когда изменения вносятся разными людьми. Если версия забронирована, ее все равно можно извлекать для чтения или компиляции. Обязательно бронировать файл, нужно только для изменения.

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

	rcs  -U  f.c     либо     rcs  -L  f.c

В командах, упомянутых выше, можно указывать и архив и рабочий файл, а можно, только один из них. В последнем случае RCS сначала ищет архив в подкаталоге RCS , затем в том же каталоге, что и заданный рабочий файл; поиск же рабочего файла начинается с текущего каталога. Удобнее держать архивы в подкаталоге RCS и не загромождать каталог с рабочими файлами. (В версии, скомпилированной для MS-DOS, это необходимо из-за невозможности добавить архивный суффикс к имени рабочего файла.)

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

	ci  -l  f.c     или     ci  -u  f.c

Обе формы регистрируют файл, не удаляя его и экономят, тем самым, одну операцию восстановления. Первый вариант не открывает файла для других, и удобен, если Вы продолжаете его, редактировать; второй удобен, если Вы закончили работу с файлом; но оба не изменят официального рабочего файла, если Вы регистрируете файл из третьего места (указав путь к обоим файлам или слинковав официальный рабочий каталог RCS в Ваш личный, где находится Ваша копия рабочего файла), и потребуется команда co в каталоге с официальным рабочим файлом, чтобы заменить его последней версией. При этом все идентификационные метки файла (см. ниже) обновляются.

Можно задать номер новой версии в качестве явного аргумента команды ci. Например, старые версии имели номера 1.1, 1.2, 1.3, и т.д., а Вы объявляете выпуск 2. Команда

	ci  -r2  f.c     или     ci  -r2.1  f.c

присвоит новой версии номер 2.1. Начиная с данной версии, версии будут нумероваться 2.2, 2.3, и т.д. соответствующая форма команды co

	co  -r2  f.c     или     co  -r2.1  f.c

востребует соответственно, либо последнюю из версий вида 2.x либо версию 2.1. Команда co со флагом -r без номера востребует последнюю версию главной ветви, т.е. лексикографически наибольший номер версии, состоящий из пары чисел. Для обозначения побочных ветвей и версий из них требуется набор большей длины. Если, например, вы хотите начать побочную ветвь вариантов от версии 1.3, наберите

	ci  -r1.3.1  f.c

Эта команда начнет ветвь 1 версии 1.3 и даст первой версии новой ветви номер 1.3.1.1. Для дополнительной информации о побочных ветвях см. в разделе формат файлов rcsfile(5).

АВТОМАТИЧЕСКАЯ ИДЕНТИФИКАЦИЯ

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

	$Id$
RCS заменит этот маркер строкой вида
	$Id:  имя-файла версия дата время автор статус $

С такой отметкой на первой странице каждого модуля легко видеть номер версии рабочего файла. RCS автоматически обновляет такие идентификационные маркеры. Если требуется включить такой маркер в объектный код, присвойте его фиктивной строковой переменной. В C это делается так:

	static char rcsid[] = "$Id$";

Команда ident позволяет определить такие маркеры в любых файлах, будь то исполняемый код или сброшенный на диск образ оперативной памяти. Это позволяет определить версии (и др. атрибуты) модулей, использованных в программе.

Другой маркер -- $Log$. Он заменяется историей изменения файла. О прочих маркерах см. co(1).

ПРОБЛЕМЫ
При системном сбое, например вызвавшем перезапуск, могут оставаться сигнальные файлы (см. ci(1) ВРЕМЕННЫЕ ФАЙЛЫ И ЛИНКИ), которые содержат информацию о том, что в данное время идет работа с архивным файлом, что не даст его изменить. Положение легко исправить, удалив сигнальные файлы, имена которых обычно или начинаются с запятой, или заканчиваются на символ подчеркивания.

СМ. ТАКЖЕ
ci(1), co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1)

Walter F. Tichy, RCS--A System for Version Control, Software--Practice & Experience 15, 7 (July 1985), 637-654.

Copyright (C) Walter F. Tichy, Paul Eggert.
Comments: info@citmgu.ru
Designed by Andrey Novikov
Copyright © CIT