Сервер поддерживается Центром Информационных Технологий (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 делает это автоматически. Кроме самих изменений текста, вносятся также дата, имя (точнее, login name) автора, дата и время внесения изменений, и, также, краткие комментарии, описывающие суть внесенных изменений. Эта, своего рода, летопись, позволяет быстро понять, что происходило с документом без трудоемкого сравнения распечаток и опроса работавших с текстом сотрудников.

• Вносит ясность в проблему доступа нескольких людей к одному и тому же тексту. Когда разные люди пытаются получить доступ ко внесению изменений одновременно, RCS предупреждает их и предотвращает затирание только что внесенных изменений.

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

• Объединять параллельные линии развития одного документа, предотвращая конфликты. RCS делает это производя "суммарное" изменение. Если же внесенные в две линии изменения затронули один и тот же фрагмент кода, RCS предупреждает пользователя о наложении изменений. Тот же механизм (см. флаг -j команды co) позволяет отменить изменение, внесенное на одном из предыдущих этапов, сохранив исправления, сделанные на последующих. Это же позволяет автоматически создавать локальные версии из новой главной и старой локальной.
• Управлять подразделением версий и конфигураций. В дополнение к тому, что возможно восстановление состояние отслеживаемой системы, существовавшее в любой заданный момент, соответственные версии всех файлов могут быть помечены одним и тем же ключевым символом. Версии может быть придан статус, обозначающий, что она является экспериментальной, стабильной, коммерческой, выпуском и др. Это позволяет просто и недвусмысленно описывать этапы развития большой системы, состоящей из многих документов.

• Автоматически отождествлять версии по имени, номеру, времени создания, автору и т.п. Идентификационные метки с ключевыми словами, вставляются в определенные места истории изменений файла. Такая схема позволяет легко выяснить, какие версии каких модулей составляют данную конфигурацию или выпуск.

• Минимизировать необходимое для хранения место. Для новой версии 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

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

	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$

	$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