1. ИМЯ
ci - оформленный ввод модификаций RCS
2. ФОРМАТ
ci [options] file...
3. ОПИСАНИЕ
ci сохраняет новые модификации в файлах RCS. Каждое имя пути, под-
ходящее для суффикса RCS, принимается за RCS-файл. Предполагается,
что все другие - это рабочие файлы, содержащие новые модификации.
Если задан только рабочий файл, то ci пытается найти соответствую-
щий файл RCS в поддиректории RCS и затем в директории рабочего
файла. Для дальнейших деталей см. ниже ИМЕНОВАНИЕ ФАЙЛОВ.
Для запуска ci регистрационное имя пользователя должно быть в
списке доступа, за исключением случаев, когда этот список пуст
или пользователь - привилегированный или владелец файла. Для до-
бавления новой модификации к существующей ветви оконечная модифи-
кация на этой ветви должна быть блокирована пользователем. Иначе
может быть только создана новая ветвь. Это ограничение не накла-
дывается на владельца файла, если используется нестрогое блокиро-
вание (см. rcs(1)). Блокировка, наложенная кем-то другим, может
быть нарушена командой rcs.
Если не задана опция -f, то ci проверяет, отличается ли размещае-
мая модификация от предшествующей. Если нет, то вместо создания
новой модификации ci обращается к предшествующей. Для такого об-
ращения обычная rcs удаляет рабочий файл и любую блокировку;
ci -l сохраняет, а ci -u устраняет любую блокировку, и затем они
обе генерируют новый рабочий файл, как если бы co -l или co -u
были применены к предшествующей модификации. При обращении любые
опции -n и -s применяются к предшествующей модификации.
Для каждой помещенной модификации ci запрашивает запись в журна-
ле. Запись в журнале должна суммировать изменения и должна окан-
чиваться символом конец_файла или строкой, содержащей в себе точ-
ку. Если оформлено введены несколько файлов, то ci запрашивает,
использовать ли вновь предыдущую запись в журнале. Если стандарт-
- 2 -
ный вход - не терминал, то ci подавляет запрос и использует одну
и ту же запись в журнале для всех файлов. См. также -m.
Если файл RCS не существует, то ci создает его и размещает содер-
жимое рабочего файла как начальную модификацию (номер по умолча-
нию: 1.1). Список доступа инициализируется как пустой. Вместо за-
писи в журнале ci затребует поясняющий текст (см. ниже -t).
Номер rev размещаемой модификации может быть задан одной из опций
-f, -i, -I, -j, -k, -l, -M, -q, -r или -u. rev может быть символь-
ным, численным или смешанным. Символические имена в rev уже должны
быть определены; см. опции -n и -N для присвоения имен при
checkin'е. Если rev = $, то ci определяет номер модификации из зна-
чений ключевых слов в рабочем файле.
Если rev начинается с точки, то эта модификация "насаживается" на
ветвь по умолчанию (в норме на ствол).Если rev - номер ветви с
точкой на конце, то используется самая поздняя модификация на
этой ветви.
Если rev - номер модификации, то он должен быть выше, чем самая
поздняя модификация на ветви, к которой принадлежит rev, или с
него должна начаться новая ветвь.
Если rev - это ветвь, а не номер модификации, то новая модифика-
ция добавляется к этой ветви. Номер уровня получается прибавлением
номера самой "верхней" модификации на этой ветви. Если rev указы-
вает на несуществующую ветвь, то такая ветвь создается с
начальной модификацией с номером rev.1.
Если rev опущена, то ci пробует вывести номер новой модификации
из последней блокировки пользователя. Если пользователь блокирует
самую верхнюю модификацию ветви, то новая модификация добавляется
к этой ветви. Номер новой модификации получается прибавлением но-
мера самой верхней модификации. Если пользователь блокировал не
самую верхнюю модификацию, то начинается новая ветвь от этой мо-
дификации прибавлением номера наивысшей ветви к этой модификации.
По умолчанию начальная ветвь и номера уровней суть 1.
- 3 -
Если rev опущена и пользователь не имеет "замка", но владеет
файлом и блокирование не установлено на строгое, то модификация
добавляется к началу ветви по умолчанию (в норме к стволу; см.
опцию -b в rcs(1)).
Исключение: на стволе модификации добавляются к концу, а не
вставляются.
4. ОПЦИИ
-rrev Оформлено вывести модификацию rev
-r Чистая опция -r (без какой-либо модификации) имеет нео-
бычное значение в ci. С другими командами RCS чистая опция
-r специфицирует самую позднюю модификацию на ветви по
умолчанию, но с ci чистая опция -r переустанавливает пове-
дение по умолчанию освобождения "замка" и удаления рабоче-
го файла и используется для перезаписи любой опции -l или
-u, устанавливаемой псевдонимами (aliases) оболочки или
командными файлами.
-l[rev]
работает как -r, за исключением того, что она совершает
дополнительно co -l для сохраненной модификации. Таким об-
разом сохраненная модификация снова немедленно оформленно
выводится и блокируется. Это полезно для сохранения моди-
фикации, хотя иногда желательно продолжать редактирование
после оформленного ввода.
-u[rev]
работает как -l, за исключением того, что сохраненная моди-
фикация не блокируется. Это позволяет читать рабочий файл
непосредственно после checkin.
Опции -l, чистая -r и -u взаимоисключающие и незаметно пе-
резаписывают (перекрывают) друг друга. Например, ci -u -r
эквивалентно ci -r, так как чистая -r перекрывает -u.
- 4 -
-f[rev]
выполняет копирование во внешнюю память; новая модификация
копируется, даже если она не отличается от предшествующей.
-k[rev]
ищет рабочий файл для значений ключевых слов, чтобы опре-
делить номер его модификации, дату создания, состояние и
автора (см. co(1)) и присваивает эти значения сохраненной
модификации, а не вычисляет их локально. Она также генери-
рует регистрационное сообщение по умолчанию, выполняющее
регистрацию пользователя, и действительную дату оформлен-
ного ввода. Эта опция полезна для готового продукта. Моди-
фикация, которая устанавливается на нескольких машинах,
должна быть оформленно введена на этих машинах с опцией -k
для сохранения первоначальных номера, даты, автора и сос-
тояния. Извлеченные значения ключевых слов и регистрацион-
ное сообщение по умолчанию могут быть перекрыты опциями
-d, -m, -s, -w и любой опцией, которая содержит номер мо-
дификации.
-q[rev]
"молчаливый" режим; диагностический выход не печатается.
Модификация, которая не отличается от предшествующей, не
копируется во внешнюю память, если не задана -f.
-i[rev]
первоначальный checkin; сообщить об ошибке, если файл RCS
уже существует. Это исключает состязания (гонки) в некото-
рых приложениях.
-j[rev]
только оформленно ввести и не инициализировать; сообщить
об ошибке, если файл RCS не существует.
-I[rev]
интерактивный режим; пользователю подсказывают и задают
вопросы, даже если стандартный вход - не терминал.
-d[date]
- 5 -
использует date как дату и время оформленного ввода. Дата
специфицируется в свободном формате, как объяснено в
co(1). Это полезно для подмены даты оформленного ввода и
для -k, если дата недоступна. Если date пуста, то исполь-
зуется время последнего модифицирования рабочего файла.
-M[rev]
устанавливает время модифицирования любого нового рабоче-
го файла по дате искомой модификации rev. Например, ci -d
-M -u f не изменяет время модифицирования для f, даже если
содержимое f изменяется из-за подстановки ключевых слов.
Используйте эту опцию осторожно; она может нарушить
make(1).
-mmsg использует строку msg как запись в журнале для всех оформ-
ленно введенных модификаций. По условию журнальные записи,
начинающиеся с #, являются комментариями и игнорируются
программами вроде пакета GNU Emacs's vc. Вдобавок, жур-
нальные записи, начинающиеся с {clumpname} (групповое имя)
(с пробелами после них), будут собраны вместе при возмож-
ности, даже если они ассоциируются с различными файлами;
{clumpname} используется только для сборки и не считается
частью самой журнальной записи.
-nname присваивает символическое имя name номеру оформленно вве-
денной модификации. ci сообщает об ошибке, если name уже
присвоено другому номеру.
-Nname то же, что -n за исключением того, что она перекрывает
предыдущее присвоение name.
-sstate
устанавливает состояние оформленно введенной модификации
для идентификатора state. Состояние по умолчанию - Exp.
-tfile записывает поясняющий текст из названного файла file в
файл RCS, убирая существующий текст. file не может начи-
наться с -.
- 6 -
-t-string
записывает поясняющий текст из строки string в файл RCS,
убирая существующий текст.
Опция -t в обеих ее формах имеет действие только во время
начального оформленного ввода; иначе она незаметно игнори-
руется.
Во время начального оформленного ввода, если -t не зада-
на, ci получает текст со стандартного ввода,
оканчивающийся символом конец_файла или строкой, содержа-
щей точку. Пользователь приглашается ко вводу текста, если
возможна интерактивная работа; см. -I.
Для обратной совместимости со старыми версиями RCS чистая
опция -t игнорируется.
-T устанавливает время модифицирования файла RCS на время
новой модификации, если прежняя предшествует последней и
есть новая модификация; иначе сохраняет время модификации
файла RCS. Если вы заблокировали модификацию, то ci обычно
обновляет время модификации файла RCS на текущее время,
так как блокировка сохраняется в файле RCS и устранение
блокировки требует изменения файла RCS. Так можно создать
файл RCS новее, чем рабочий файл. одним из двух способов:
(1) ci -M может создать рабочий файл с датой до текущего
времени; (2) при обращении к предыдущей модификации файл
RCS может измениться, тогда как рабочий файл останется не-
изменным. Эти два случая могут вызвать лишнюю перекомпиля-
цию, вызванную зависимостью рабочего файла от RCS файла
через make(1). Опция -T запрещает такую перекомпиляцию пу-
тем подмены даты файла RCS. Используйте эту опцию осторож-
но; она может подавить перекомпиляцию, даже когда оформ-
ленный ввод одного рабочего файла должен воздействовать на
другой рабочий файл, ассоциированный с тем же файлом RCS.
Предположим, что время файла RCS - 01:00, время измененно-
го рабочего файла -02:00, какая-то еще копия рабочего фай-
ла имеет время 03:00, а текущее время - 04:00. Тогда ci -d
-T устанавливает время файла RCS на 02:00 вместо обычного
- 7 -
04:00; это заставляет make(1) думать (неправильно), что
последняя копия новее, чем файл RCS.
-wlogin
использует login как поле автора помещаемой модификации.
Полезна для подмены поля автора и для -k, если автор не-
доступен.
-V Печатает номер версии RCS.
-Vn Эмулирует RCS версии n. См. co(1) для деталей.
-xsuffixes
специфицирует суффиксы suffixes для файлов RCS. Непустой
суффикс соответствует любому имени пути, оканчивающемуся
на этот суффикс. Пустой суффикс соответствует любому имени
пути в форме RCS/путь или путь1/RCS/путь2. Опция -x может
специфицировать список суффиксов, разделенных /. Например,
-x,v/ специфицирует два суффикса: ,v и пустой суффикс. Ес-
ли специфицируются два или более суффикса, то они рассмат-
риваются по порядку при просмотре файла RCS; первый срабо-
тавший используется для этого файла. Если не найдено
файла RCS, но файл RCS может быть создан, то суффиксы
рассматриваются для определения имени нового файла RCS.
Умолчание для суффиксов зависимо от инсталляции; в норме
это ,v/ для машин типа Unix, которые позволяют запятые в
именах файлов, и пустой суффикс для других машин.
-zzone специфицирует выходной формат даты в подстановке ключевых
слов и часовой пояс по умолчанию для даты в опции -ddate.
zone должна быть или пустой, или численным смещением КВВ,
или специальной строкой LT для местного времени. Умолчание
- пустой пояс, который использует традиционный RCS-формат
для КВВ без указания на часовой пояс и со слэшами, разде-
ляющими части даты; иначе времена выводятся в формате ISO
8601 с указанием часового пояса. Например, если местное
время - 11 января 1990 г., 8pm (8 часов вечера) Тихоокеан-
ского Стандартного Времени, восемь часов к западу от КВВ,
то выход времени будет такой:
- 8 -
опция выход времени
-z 1990/01/12 04:00:00 (умолчание)
-zLT 1990-01-11 20:00:00-08
-z+05:30 1990-01-12 09:30:00+05:30
Опция -z не воздействует на даты, хранимые в файлах RCS,
которые всегда КВВ.
5. ИМЕНОВАНИЕ ФАЙЛОВ
Пары файлов RCS и рабочих файлов могут быть специфицированы тремя
способами (см. также раздел примеров).
1) Даны и файл RCS и рабочий файл. Имя пути RCS имеет форму
путь1/раб_файлX, а рабочее имя пути имеет форму
путь2/раб_файл,где путь1/ и путь2/ - (возможно, различные или
пустые) пути, раб_файл - имя файла, а X - RCS-суффикс. Если X
пусто, то путь1/ должен начинаться с RCS/ или должен содержать
/RCS/.
2) Дан только файл RCS. Рабочий файл создается в текущем директо-
рии и его имя выводится из имени файла RCS удалением путь1/ и
суффикса X.
3) Дан только рабочий файл. Тогда ci рассматривает каждый
RCS-суффикс X по очереди, ища файл RCS в форме путь2/RCS/раб_файл
или (если прежний не найден и X непусто) путь2/раб_файлX.
Если файл RCS специфицирован без пути в 1) и 2), то ci ищет файл
RCS первый в директории ./RCS и затем в текущем директории.
ci сообщает об ошибке, если попытка открыть файл RCS не удается
по необычной причине, даже если имя пути файла RCS - это только
одна из нескольких возможностей. Например, для подавления ис-
пользования команд RCS в директории d создать регулярный файл с
именем d/RCS, так чтобы случайные попытки использовать команды
RCS в d оканчивались неудачей из-за того, что d/RCS - не директо-
рий.
- 9 -
6. ПРИМЕРЫ
Пусть ,v - RCS-суффикс и текущий директорий содержит поддиректо-
рий RCS с файлом RCS io.c,v. Тогда каждая из следующих команд
оформленно вводит копию io.c в RCS/io.c,v как самую позднюю моди-
фикацию, удаляя io.c.
ci io.c; ci RCS/io.c,v; ci io.c,v;
ci io.c RCS/io.c,v; ci io.c io.c,v;
ci RCS/io.c,v io.c; ci io.c,v io.c;
Пусть вместо этого пустой суффикс - это RCS-суффикс и текущий ди-
ректорий содержит поддиректорий RCS с файлом RCS io.c. Каждая из
следующих команд оформленно вводит новую модификацию.
ci io.c; ci RCS/io.c;
ci io.c RCS/io.c;
ci RCS/io.c io.c;
7. ФАЙЛОВЫЕ РЕЖИМЫ
Файл RCS, созданный ci, наследует права чтения и исполнения от
рабочего файла. Если файл RCS уже существует, то ci сохраняет его
права на чтение и исполнение. ci выключает все права записи фай-
лов RCS.
8. ФАЙЛЫ
Временные файлы создаются в директории, содержащем рабочий файл и
также в рабочем директории (см.TMPDIR в разделе СРЕДА).Семафорный
файл или файлы создаются в директории, содержащем файл RCS. С не-
пустым суффиксом имена семафоров начинаются с первого символа
суффикса; следовательно, не специфицируйте суффикс, чей первый
символ может оказаться первым символом имени рабочего файла. С
пустым суффиксом имена семафоров кончаются на _ , так что имена
рабочих файлов не должны кончаться на _ .
ci не изменяет файл RCS или рабочий файл. В норме ci снимает свя-
зи с файла и создает новый; но вместо разрушения цепочки из одной
или нескольких связей к файлу RCS она отключает связи к результи-
рующему файлу. Следовательно, ci разрушает любые жесткие или сим-
вольные связи к любому рабочему файлу, который она изменяет; и
- 10 -
жесткие связи к файлам RCS являются бездействующими, но символь-
ные связи к файлам RCS сохраняются.
Опытный пользователь должен уметь искать и записывать директорий,
содержащий файл RCS. В норме обычный пользователь должен уметь
читать файлы RCS и рабочие файлы и искать и записывать директо-
рий, содержащий рабочий файл; однако некоторые старые машины не
могут легко переключаться между обычным и опытным пользователями,
так что на этих машинах опытный пользователь имеет доступ ко всем
возможностям. Опытный пользователь - это то же, что обычный поль-
зователь, если ваши копии ci и co не имеют привилегий установки
идентификаторов пользователя. Как описано в следующем разделе,
эти привилегии создают повышенную безопасность, если опытный
пользователь владеет всеми файлами RCS и директориями и если
опытный пользователь может записывать директории RCS.
Пользователи могут управлять доступом к файлам RCS установкой
прав (разрешений) на директорий, содержащий файлы; только пользо-
ватели с правом записи в директорий могут использовать команды
RCS для изменения его файлов RCS. Например, в машинах, которые
разрешают пользователю принадлежать к нескольким группам, можно
сделать групповые директории RCS перезаписываемыми только для
этой группы. Этот подход достаточен для неформальных проектов, но
он означает, что любой член группы может произвольно изменять
групповые файлы RCS и может даже полностью их удалять. Поэтому
более формальные проекты иногда делают различие между администра-
тором RCS, который может изменять файлы RCS по своему желанию, и
другими членами проекта, которые могут оформленно вводить новые
модификации, но не могут иным способом изменять файлы RCS.
9. ИСПОЛЬЗОВАНИЕ УСТАНОВКИ ИДЕНТИФИКАТОРОВ ПОЛЬЗОВАТЕЛЯ (УИП)
Для предотвращения удаления модификаций кем-либо. кроме админист-
ратора RCS, пользователи могут использовать привилегии УИП следу-
ющим образом.
- Проверить, что машина поддерживает использование УИП RCS. Про-
консультироваться с достойным доверия экспертом, если есть
сомнения. Лучше всего, если вызов системы УИП работает, как
описано в Posix 1003.1a Draft 5, так как RCS может легко пе-
реключаться между реальным и номинальным пользователями, даже
- 11 -
если реальный пользователь - это root. Если нет, то лучше, ес-
ли вызов системы УИП поддерживает сохраненный УИП (поведение
{_POSIX_SAVED_IDS} в Posix 1003.1-1990); это не удается только
если реальный или номинальный пользователь - это root. Если
RCS обнаруживает несрабатывание в УИП, то она немедленно выхо-
дит.
- Выбрать пользователя A в качестве администратора RCS для набора
пользователей. Только A может вызывать команду rcs на пользо-
вательских файлах RCS. A не должен быть root'ом или любым дру-
гим пользователем со специальными полномочиями. Множества
пользователей, взаимно не доверяющие друг другу, должны иметь
разных администраторов.
- Выбрать имя пути B для директория файлов, которые будут испол-
няться пользователями.
- Пользователю A ввести в B копии ci и co, которые являются УИП
для A, путем копирования команд из их директория D стандартной
инсталляции следующим образом:
mkdir B
cp D/c[io] B
chmod go-w,u+s B/c[io]
- Каждому пользователю добавлять B к началу его пути следующим
образом:
PATH=B:$PATH; export PATH # обычная оболочка
set path=(B $path) # оболочка C
- Пользователю A создавать каждый RCS-директорий R с правом запи-
си только для A следующим образом:
mkdir R
chmod go-w R
- Если вы хотите позволить только некоторым пользователям читать
файлы RCS, то поместите этих пользователей в группу G, а поль-
- 12 -
зователю A следует далее защищать RCS-директорий следующим об-
разом:
chgrp G R
chmod g-w,o-rwx R
- Пользователю A скопировать старые файлы RCS (если есть) в R
для обеспечения A правом их владения.
- Список доступа файлов RCS ограничивается теми, кто может оформ-
ленно вводить и блокировать модификации. По умолчанию список
доступа пуст, что дает доступ к оформленному вводу любому, кто
может читать файлы RCS. Если вы хотите ограничить доступ к
оформленному вводу, то пользователю A следует вызвать rcs -a
для файла; см. rcs(1). В частности, rcs -e -aA ограничивает
доступ только пользователем A.
- Пользователю A инициализировать любой новый файл RCS при помощи
rcs -i перед начальным оформленным вводом, добавляя опцию -a,
если вы хотите ограничить доступ к оформленному вводу.
- Дать привилегии УИП только для ci, co и rcsclean; не давать их
rcs или любой другой команде.
- Не использовать другие УИП-команды для вызова команд RCS; УИП
более замысловат, чем вы думаете!
10. СРЕДА
RCSINIT Опции добавляются к началу списка аргументов, разделен-
ных пробелами. Обратный слэш позволяет включать пробелы
в опцию. Опции RCSINIT добавляются к началу списка аргу-
ментов большинства команд RCS. Полезные опции RCSINIT
включают -q, -V, -x и -z.
TMPDIR Имя временного директория.Если оно не установлено,то тог-
да проверяются переменные среды TMP и TEMP и берется
первое найденное значение; если они не установлены, то
используется машинно-зависимое умолчание, обычно /tmp.
11. ДИАГНОСТИКА
Для каждой модификации ci печатает файл RCS, рабочий файл и чис-
ло сохраненных и предшествующих модификаций. Статус выхода = 0,
если и только если все операции были успешными.
12. ИДЕНТИФИКАЦИЯ
Автор: Walter F. Tichy.
Manual Page Revision: 5.17; Release Date: 1995/06/16.
Copyright (C) 1982, 1988, 1989 Walter F. Tichy.
Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul
Eggert.
13. СМ. ТАКЖЕ
co(1), emacs(1), ident(1), make(1), rcs(1), rcsclean(1),
rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1), setuid(2),
rcsfile(5)
Walter F. Tichy, RCS--A System for Version Control,
Software--Practice & Experience 15, 7 (July 1985),
637-654.
