Репозиторий в CVS хранит полные копии всех файлов и каталогов, находящихся под контролем версий.
Обычно вам никогда не придется напрямую обращаться к файлам в репозитории. Вместо этого вы будете использовать команды CVS для получения вашей личной копии файлов в рабочем каталоге, а затем будете работать с этими файлами. Когда вы внесли определенные изменения, вы фиксируете их в репозитории. Теперь в репозитории хранится информация о том, какие изменения вы сделали, включая их точное содержание, время изменения и тому подобную информацию. Заметьте, что репозиторий не является подкаталогом рабочего каталога, и обратное также неверно; они находятся в совершенно разных местах.
CVS может обращаться к репозиторию большим количеством способов. Репозиторий может находиться на локальной машине, на соседней машине или на машине, находящейся на другом континенте. Чтобы различать пути доступа к репозиториям, их имена начинаются с метода доступа. Например, метод доступа `:local:' означает, что репозиторий находится в локальном каталоге, то есть `:local:/usr/local/cvsroot' означает, что репозиторий находится в `/usr/local/cvsroot' на компьютере, на котором используется CVS. Другие методы доступа описаны в section Сетевые репозитории.
Если метод доступа не указан, и имя репозитория не содержит
`:', то предполагается метод :local:. Если в имени
содержится `:', то предполагается метод доступа :ext:
или :server:. Например, если ваш локальный репозиторий
находится в `/usr/local/cvsroot', то вы можете использовать
/usr/local/cvsroot вместо
:local:/usr/local/cvsroot. Но если, например, под
Windows NT ваш локальный репозиторий находится в
`c:\src\cvsroot', то вы должны указать метод доступа, то
есть :local:c:\src\cvsroot.
Репозиторий делится на две части. `$CVSROOT/CVSROOT' содержит административные файлы CVS. Все прочие каталоги содержат модули, определенные пользователем.
Существует несколько способов сообщить CVS, где искать
репозиторий. Вы можете явно задать репозиторий в командной
строке с помощью опции -d ("directory", каталог):
cvs -d /usr/local/cvsroot checkout yoyodyne/tc
Другим вариантом является установка переменной окружения
$CVSROOT в полный путь до корня репозитория, например,
`/usr/local/cvsroot'. Чтобы установить $CVSROOT,
пользователи csh и tcsh должны поместить в свой
файл `.cshrc' или `.tcshrc' такую строку:
setenv CVSROOT /usr/local/cvsroot
Пользователи sh и bash должны поместить в свой файл
`.profile' или `.bashrc' такие строки
CVSROOT=/usr/local/cvsroot
export CVSROOT
Имя репозитория, указанное с помощью -d, будет
использоваться вместо указанного в переменной окружения
$CVSROOT. Когда вы извлечете рабочую копию из
репозитория, эта копия будет помнить, из какого именно
репозитория ее извлекли (эта информация хранится в файле
`CVS/Root' в рабочем каталоге).
Опция -d и файл `CVS/Root' переопределяют
репозиторий, заданный в переменной окружения $CVSROOT.
Если репозиторий, заданный опцией -d, отличается от
репозитория, указанного в файле `CVS/Root', используется
первый из них. Конечно же, для правильного функционирования
должно быть несколько способов обращаться к одному и тому же
репозиторию.
В большинстве случаев неважно, как именно CVS хранит информацию в репозитории. В действительности, формат уже менялся однажды и, скорее всего, изменится в будущем. Так как в большинстве случаев весь доступ к репозиторию происходит посредством команд CVS, такие изменения не приводят к каким-либо разрушениям.
Однако, в некоторых случаях необходимо точно знать, как CVS хранит данные в репозитории, например, если вы хотите отследить блокировки файлов, которые делает CVS (see section Совместный доступ нескольких разработчиков к CVS) или вам потребуется изменить права доступа к файлам в репозитории.
Общая структура репозитория -- это дерево каталогов,
соответствующее каталогам в рабочей копии. Предположим,
например, что репозиторий находится в
/usr/local/cvsroot
Вот возможное дерево каталогов (показаны только каталоги):
/usr
|
+--local
| |
| +--cvsroot
| | |
| | +--CVSROOT
| (административные файлы)
|
+--gnu
| |
| +--diff
| | (исходный текст GNU diff)
| |
| +--rcs
| | (исходный текст RCS)
| |
| +--cvs
| (исходный текст CVS)
|
+--yoyodyne
|
+--tc
| |
| +--man
| |
| +--testing
|
+--(другое программное обеспечение фирмы Yoyodyne)
Внутри каталогов находятся файлы истории для каждого файла,
находящегося под контролем версий. Имя файла истории -- это имя
соответствующего файла с добавленным в конце `,v'. Вот как
выглядит дерево каталогов для `yoyodyne/tc':
$CVSROOT
|
+--yoyodyne
| |
| +--tc
| | |
+--Makefile,v
+--backend.c,v
+--driver.c,v
+--frontend.c,v
+--parser.c,v
+--man
| |
| +--tc.1,v
|
+--testing
|
+--testpgm.t,v
+--test2.t,v
Файл истории содержит, помимо всего прочего, достаточно информации, чтобы воссоздать любую редакцию файла, журнал всех зафиксированных изменений и имена всех пользователей, сделавших эти изменения. Файлы истории известны как RCS-файлы, потому что первой программой, которая создавала файлы этого формата, была система контроля версий RCS. Полное описание формата файлов находится на странице руководства rcsfile(5), распространяемого вместе с RCS, или в файле `doc/RCSFILES' в комплекте исходных текстов CVS. Этот формат файла используется повсеместно -- множество других программ могут по меньшей мере импортировать файлы этого формата.
Файлы RCS, используемые в CVS, отличаются от стандартного формата в нескольких местах. Наличие волшебных веток -- Самое большое отличие; смотри section Волшебные номера веток. Имена меток, которые позволяет использовать CVS, являются подмножеством тех, что позволены в RCS; смотри главу section Метки ревизий.
Все файлы `,v' создаются с правами только для чтения, и вам
не следует изменять права доступа к этим файлам. Каталоги в
репозитории должны быть доступны для записи тем, кому разрешено
изменять файлы в каждом каталоге. Это обычно означает, что вам
нужно создать группу UNIX (см. group(5)), состоящую из
лиц, участвующих в создании проекта, и настроить репозиторий так,
чтобы эта группа владела каталогом с проектом.
Это означает, что ограничивать доступ к файлам можно только на уровне каталога.
Заметьте, что пользователи также должны иметь права на запись для извлечения файлов, потому что CVS должна создавать файлы блокировки (see section Совместный доступ нескольких разработчиков к CVS).
Заметьте также, что пользователи должны иметь права на запись в файл `CVSROOT/val-tags'. CVS использует этот файл, чтобы отслеживать, какие метки разрешены (этот файл иногда обновляется, когда используются и когда создаются метки).
Каждый RCS-файл принадлежит пользователю, который последним зафиксировал изменения в этот файл. Этот факт не столь важен, главное -- кто владеет каталогами.
CVS пытается установить адекватные права доступа к файлам
для новых каталогов, которые создаются в дереве, но если вам
требуется, чтобы новый каталог имел права доступа, отличающиеся
от его родительского каталога, вы должны задать это вручную.
Если вы установите переменную окружения CVSUMASK, то она
будет задавать, какие права доступа к файлам CVS использует
при создании каталогов и/или файлов в репозитории.
CVSUMASK не влияет на права доступа к файлам в рабочем
каталоге; такие файлы имеют права, обычные для новых файлов,
разве что только иногда CVS создает их с правами только для
чтения (смотри главу о слежении, section Слежение за чужими исходными текстами; -r, section Глобальные ключи командной строки; или CVSREAD,
section Все переменные окружения, используемые в CVS).
Заметьте, что при использовании клиент-серверного CVS
(see section Сетевые репозитории) не существует нормального способа
установить CVSUMASK; установка его на клиентской машине не
играет роли. Если вы соединяетесь с помощью rsh, вы
можете установить CVSUMASK в файле `.bashrc' или
`.cshrc', как описано в документации на вашу операционную
систему. Это поведение может измениться в будущей версии
CVS; не полагайтесь на то, что установка CVSUMASK на
клиентской машине не играет роли.
При использовании pserver обычно требуются гораздо более жесткие
права доступа к каталогу CVSROOT и каталогам, находящимся в
CVSROOT; see section Настройка сервера для парольной аутентификации.
Некоторые операционные системы позволяют определенным программам выполнять операции, которые не может выполнять тот, кто вызывает эти программы. Например, возможности setuid или setgid в UNIX или установленные образы в VMS. CVS не разрабатывался, чтобы использовать такие возможности, и поэтому попытки установить CVS таким образом обеспечат защиту только лишь от случайных ошибок; те, кто желает обойти защиту, смогут это сделать и, в зависимости от конкретных условий, смогут получить доступ еще куда-либо помимо CVS. Вы можете попробовать использовать pserver. Эта возможность также способна дать ложное чувство безопасности или открыть дыру, больше чем та, которую вы пытаетесь закрыть, поэтому внимательно прочтите документацию на безопасность pserver, если вы собираетесь его использовать (section Настройка сервера для парольной аутентификации).
Некоторые вопросы, связанные с правами доступа, специфичны для операционных систем класса Window (Windows 95/98, Windows NT и, скорее всего, будущие подобные операционные системы. Часть нижесказанного может быть применима к OS/2, хотя я не уверен).
Вы заметите, что иногда CVS помещает RCS-файлы в
каталоге Attic ("чердак"). Например, если CVSROOT -- это
`/usr/local/cvsroot', и мы говорим о файле `backend.c'
в каталоге `yoyodyne/tc', то обычно этот файл находится в
/usr/local/cvsroot/yoyodyne/tc/backend.c,v
Если же он попадает на чердак, то он будет находиться в
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
С точки зрения пользователя неважно, находится файл на чердаке
или нет, так как CVS сам следит за этим и при необходимости
заглядывает на чердак в поисках файла. В случае же, если вы
хотите знать точно, то RCS-файл хранится на чердаке тогда и
только тогда, когда головная ревизия ствола находится в состоянии
dead ("мертвое"). "Мертвое" состояние означает, что файл
был удален или же никогда не добавлялся в эту ветку. Например,
если вы добавите файл в ветку, то его стволовая ревизия будет в
"мертвом" состоянии, а ревизия на ветке -- нет.
Каталог `CVS' в каждом репозитории содержит информацию об атрибутах файлов (в файле `CVS/fileattr'); смотри `fileattr.h' среди исходных текстов CVS за дополнительной информацией. В будущем в этом каталоге могут оказать другие дополнительные файлы, поэтому сегодняшние реализации должны игнорировать неизвестные файлы.
Это поведение реализовано только в версиях CVS 1.7 и выше, смотри section Использование слежений со старыми версиями CVS.
Видимое пользователем поведение блокировок CVS описано в section Совместный доступ нескольких разработчиков к CVS. Эта глава ориентирована на людей, пишущих утилиты, обращающиеся к репозиторию CVS, не конфликтуя при этом с другими программами, обращающимися к тому же репозиторию. Если вы запутаетесь в описываемых здесь концепциях, как то блокировка чтения, блокировка записи и мертвая блокировка, то обратитесь к литературе по операционным системам или базам данных.
Файлы в репозитории, чьи имена начинаются с `#cvs.rfl' --- это блокировки чтения. Файл, чьи имена начинаются с `#cvs.wfl' -- это блокировки записи. Старые версии CVS (перед CVS 1.5) создавали также файлы с именами, начинающимися с `#cvs.tfl', но такие файлы здесь не обсуждаются. Каталог `#cvs.lock' служит главной блокировкой, то есть перед тем, как создавать какую-либо еще блокировку, сначала необходимо создать главную блокировку.
Чтобы создать блокировку чтения, сначала создайте каталог `#cvs.lock'. В большинстве операционных систем операция создания каталога атомарна. Если попытка создания провалилась, значит, главная блокировка уже существует, поэтому подождите немного и попробуйте еще. После получения блокировки `#cvs.lock' создайте файл, чье имя состоит из `#cvs.rfl', и информацией по вашему выбору, например, имя машины и номер процесса. Потом удалите каталог `#cvs.lock', чтобы отменить главную блокировку. Теперь вы можете читать репозиторий. Когда чтение окончено, удалите файл `#cvs.rfl', чтобы отменить блокировку чтения.
Чтобы получить блокировку записи, сначала создайте каталог `#cvs.lock', как и в случае с блокировкой чтения. Затем убедитесь, что в репозитории нет файлов, чьи имена начинаются с `#cvs.rfl'. Если они имеются, удалите `#cvs.lock', подождите немного и попробуйте снова. Если блокировок чтения нет, создайте файл с именем, состоящим из `#cvs.wfl' и какой-нибудь информации по вашему выбору, например, имени машины и номера процесса. Не удаляйте блокировку `#cvs.lock'. Теперь вы можете писать в репозиторий. Когда запись окончена, сначала удалите файл `#cvs.wfl', а затем каталог `#cvs.lock'. Заметьте, что в отличие от файла `#cvs.rfl', файл `#cvs.wfl' имеет чисто информационное значение; он не оказывает блокирующего эффекта, который в данном случае достигается использованием главной блокировки (`#cvs.lock').
Заметьте, что каждая блокировка (чтения или записи) блокирует единственный каталог в репозитории, включая `Attic' и `CVS', но не включая подкаталоги, которые представляют собой другие каталоги, находящиеся под контролем версий. Чтобы заблокировать целое дерево, вам следует заблокировать каждый каталог (заметьте, что если вы не сможете получить хотя бы одну блокировку в этом процессе, то следует отменить все уже полученные блокировки, затем подождать и попробовать снова, во избежание мертвых блокировок.)
Заметьте также, что CVS ожидает, что доступ к отдельным
файлам `foo,v' контролируется блокировками записи.
RCS использует в качестве блокировок файлы `,foo,', но
CVS не поддерживает такую схему, поэтому рекомендуется
использование блокировки записи. Смотри комментарии к
rcs_internal_lockfile в исходном коде CVS, где
находится дополнительное обсуждение и мотивация.
Каталог `$CVSROOT/CVSROOT' содержит различные административные файлы. В каком-то смысле этот каталог подобен любому другому каталогу в репозитории; он содержит RCS-файлы, чьи имена заканчиваются на `,v', и многие команды CVS оперируют с ними обычным образом. Однако, имеется несколько различий.
Для каждого административного файла, в дополнение к
RCS-файлу, хранится его последняя ревизия. Например, есть
RCS-файл `loginfo,v' и файл `loginfo', содержащий
последнюю ревизию, находящуюся в `loginfo,v'. Когда вы
фиксируете административный файл, CVS должен написать:
cvs commit: Rebuilding administrative file database
и обновить его извлеченную копию в `$CVSROOT/CVSROOT'. Если это не так, значит, что-то случилось с CVS (see section Что делать с ошибками в CVS и этом руководстве?). Чтобы ваши CVS обращался с вашими собственными файлами точно так же, вы можете добавить их имена в административный файл `checkoutlist'.
По умолчанию, файл `modules' ведет себя как описано
выше. Если же он становится очень большим, то хранение в виде
плоского файла может привести к медленному поиску модулей (я не
уверен, что это все еще столь же важно, как и тогда, когда эта
возможность впервые появилась; я не видел расчетов
быстродействия). Таким образом, внеся определенные изменения в
исходный код CVS, можно хранить файл модулей в базе данных,
которая имеет интерфейс с ndbm, например, Berkeley db или
GDBM. Если эта опция используется, то база данных модулей
будет храниться в файлах `modules.db', `modules.pag'
и/или `modules.dir'.
Информация о назначении разнообразных административных файлов находится в section Справочник по административным файлам.
Пока мы описываем внутреннюю работу CVS, которая иногда
становится видна, мы можем также поговорить о том, что CVS
хранит в каталогах `CVS' в рабочих каталогах. Как и в
случае с репозиторием, CVS обрабатывает эту информацию, и
обычно вы обращаетесь к ней посредством команд CVS. В
некоторых случаях, однако, бывает полезно напрямую работать с
содержимым этих каталогов, например, в графической оболочке
jCVS или пакете VC для emacs. Такие программы
должны следовать рекомендациям в этой главе, если они желают
нормально работать совместно с другими программами, использующими
те же самые файлы, включая будущие их версии, а также с CVS,
работающим из командной строки.
Каталог `CVS' содержит несколько файлов. Программы, читающие этот каталог, должны игнорировать файлы, находящиеся в этом каталоге, но не документированные здесь, чтобы дать возможность развития в будущем.
Файлы хранятся в текстовом формате, соответствующем соглашениям операционной системы. Это означает, что рабочие каталоги не переносимы между системами с разными форматами хранения текстовых файлов. Это сделано специально, исходя из того, что сами файлы, находящиеся под управлением CVS, вероятно, также не переносимы между такими платформами.
cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
`Root' будет содержать
:local:/usr/local/cvsroot
а `Repository' будет содержать или
/usr/local/cvsroot/yoyodyne/tc
или
yoyodyne/tc
Если рабочий каталог не имеет соответствующего каталога в
репозитории, то `Repository' должен содержать
`CVSROOT/Emptydir'.
/имя/ревизия/метка времени[+конфликт]/опции/тэг или дата
где `[' и `]' не являются частью строки, но указывают,
что `+' и отметка о конфликте не обязательны. name
--- это имя файла в каталоге. ревизия -- это номер
ревизии, на которой основан файл в рабочем каталоге, или `0'
для добавленного файла, или `-', за которым следует номер
ревизии, для удаленного файла. метка времени -- это время,
когда CVS создала этот файл; если это время отличается от
текущего времени модификации файла, значит, он был изменен.
Метка времени записывается в UTC (по гринвичу), в формате,
используемом функцией стандарта ISO C asctime() (например,
`Sun Apr 7 01:29:26 1996'). Можно написать также строку в
другом формате, например, `Result of merge', чтобы указать,
что файл всегда должен считаться измененным. Эта строка -- вовсе
не специальный случай: чтобы узнать, изменился ли файл, CVS
берет дату модификации файла и просто сравнивает строку со
строкой метка времени. конфликт указывает, что
произошел конфликт. Если эта строка совпадает с действительным
временем модификации, значит, пользователь еще не справился с
конфликтом. опции содержат прилипшие ключи командной
строки (например, `-kb' для двоичных файлов). тэг или
дата содержит либо `T', за которой следует имя тэга, либо
`D', за которой следует прилипший тэг или дата. Заметьте,
что если метка времени содержит пару меток времени,
разделенных пробелом, а не единственную метку времени, значит, вы
имеете дело с версией CVS ранее 1.5 (этот случай здесь не
документирован).
Если первый символ в строке в файле `Entries' -- это
`D', это означает подкаталог. `D' на отдельной строке
указывает, что программа, которая создала файл `Entries',
умеет обращаться с подкаталогами (то есть, если такая строка
присутствует, и нет других строк, начинающихся с `D',
значит, подкаталогов нет). В противном случае строка выглядит
так:
D/имя/заполнитель1/заполнитель2/заполнитель3/заполнитель4
где имя -- это имя подкаталога, а все поля
заполнитель должны игнорироваться, в целях будущих
расширений. Программы, изменяющие файлы `Entries', должны
сохранять значения этих полей.
Строки в файле `Entries' могут быть в любом порядке.
update с опцией `-d', чтобы получить
дополнительные файлы и удалить `Entries.Static'.
edit или
unedit), которые еще не было отосланы на сервер. Их
формат еще не документирован здесь.
edit сохраняет
исходную копию файла в каталоге `Base'. Это позволяет
команде unedit работать, даже если нет доступа к серверу.
Bимя/ревизия/расширение
поле расширение должно быть проигнорировано, для
будущих расширений.
Каталог `$CVSROOT/CVSROOT' содержит несколько
административных файлов. Полное их описание в
See section Справочник по административным файлам. Можно использовать CVS и без этих
файлов, но некоторые команды лучше работают, если хотя бы файл
`modules' должным образом настроен. В сущности, этот файл
является наиболее важным, в нем описываются все модули в
репозитории. Вот пример этого файла:
CVSROOT CVSROOT
modules CVSROOT modules
cvs gnu/cvs
rcs gnu/rcs
diff gnu/diff
tc yoyodyne/tc
Файл `modules' представляет собой текстовый файл. В
простейшем случае каждая строка содержит имя модуля, пробел и имя
каталога, где находится этот модуль, относительно
$CVSROOT.
Строка, которая определяет модуль `modules', использует возможности, здесь не описанные. Полное описание всех доступных возможностей находится в See section Файл `modules'.
Административные файлы можно редактировать точно так же, как и любой другой модуль. Используйте `cvs checkout CVSROOT', чтобы получить рабочий каталог, редактируйте его и зафиксируйте изменения обычным образом.
Случается, что фиксируется административный файл с ошибкой. Обычно можно исправить ошибку и зафиксировать новую версию, но иногда особенно серьезная ошибка может привести к невозможности фиксирования изменений.
Иногда необходимо иметь много репозиториев, например, если у вас
есть две группы разработчиков, работающих над разными проектами,
у которых нет общего кода. Все, что вам требуется, чтобы
работать с несколькими репозиториями -- указать необходимый,
используя переменную среды CVSROOT, опцию CVS
`-d' или (если у вас уже есть рабочий каталог) просто
работая по умолчанию с тем репозиторием, из которого был извлечен
рабочий каталог (see section Как сообщить CVS, где находится репозиторий.
Серьезным преимуществом нескольких репозиториев является то, что
они могут находиться на различных серверах. При использовании
CVS 1.10 единственная команда может работать с каталогами из
разных репозиториев. С помощью разрабатываемых версий CVS
можно извлекать исходные тексты с нескольких серверов. CVS
сам разберется с обходом дерева каталогов и соединениями с
разными серверами при необходимости. Вот пример создания
рабочего каталога:
cvs -d server1:/cvs co dir1
cd dir1
cvs -d server2:/root co sdir
cvs update
Команды cvs co создают рабочий каталог, а команда
cvs update соединится с server2, чтобы обновить
каталог `dir1/sdir', и с server1, чтобы обновить все
остальное.
Чтобы настроить CVS-репозиторий, сначала выберите машину и диск, на котором будет храниться история ревизий исходных текстов. Требования к процессору и памяти умеренны, поэтому подойдет практически любая машина. Детали описаны в section Требования к серверу.
Если вы импортируете RCS-файлы из другой системы, начальное дисковое пространство можно оценить как суммарный размер этих файлов. В дальнейшем можно рассчитывать на троекратный размер исходных текстов, которые вы будете хранить под контролем версий (когда-нибудь вы перерастете этот предел, но не слишком скоро). На машинах разработчики требуется дисковое пространство для рабочего каталога каждого разработчика (все дерево или его кусок, в зависимости от того, над чем работает программист).
К репозиторию должен быть доступ (прямой или с помощью сетевой файловой системы) со всех машин, которые будут использовать CVS в серверном или локальном режиме; клиентские машины не требуют никакого доступа к репозиторию кроме протокола CVS. Использование CVS для доступа только для чтения все равно требует прав на запись в репозиторий для создания файлов блокировок (see section Совместный доступ нескольких разработчиков к CVS).
Чтобы создать репозиторий, выполните команду cvs init.
Она создаст пустой репозиторий в корневом каталоге CVS,
заданном обычным образом (see section Репозиторий). Например,
cvs -d /usr/local/cvsroot init
cvs init следит, чтобы не перезаписать уже существующие
файлы, поэтому никакого вреда от запуска cvs init по уже
настроенному репозиторию не произойдет.
cvs init включит журналирование истории; если вы не хотите
этого, удалите файл истории после выполнения cvs init.
See section Файл history.
Файлы в репозитории, в сущности, не обладают никакими особыми свойствами, в большинстве случаев можно делать их резервные копии как обычно. Есть, однако, несколько аспектов, которые необходимо учитывать.
Во-первых, с параноидальной точки зрения, следует либо не использовать CVS во время резервного копирования, либо сделать так, чтобы программа резервного копирования блокировала репозиторий в процессе. Чтобы не использовать CVS, вы можете запретить логины на машины, которые могут иметь доступ к репозиторию, отключить CVS-сервер или сделать что-либо подобное. Детали зависят от вашей операционной системы и от настройки CVS. Чтобы заблокировать CVS, создайте файлы блокировок (`#cvs.rfl') в каждом каталоге репозитория. См. section Совместный доступ нескольких разработчиков к CVS за дополнительной информацией о блокировках CVS. Даже учитывая вышесказанное, если вы просто скопируете файлы, ничего особенно страшного не произойдет. Однако, при восстановлении из резервной копии репозиторий может находиться в неустойчивом состоянии, что, впрочем, нетрудно исправить вручную.
Когда вы восстанавливаете репозиторий из резервной копии, предполагая, что репозиторий изменился с момента последнего резервного копирования, рабочие каталоги, которые не пострадали, могут ссылаться на ревизии, не существующие более в репозитории. Попытка выполнения CVS в таких каталогах приведет к сообщению об ошибке. Один из способов вернуть все изменения в репозиторий таков:
cvs update и cvs diff, чтобы выяснить, что
изменилось, а затем зафиксируйте изменения в репозиторий.
Точно так же, как и в случае с резервным копированием файлов, перемещение репозитория с места на место сводится к перемещению набора файлов.
Основная вещь, которую нужно учитывать -- это то, что рабочие каталоги ссылаются на репозиторий. Самый простой способ справиться с этим -- получить свежий рабочий каталог после перемещения. Конечно, вам следует сначала убедиться, что старый рабочий каталог был зафиксирован перед перемещением, или вы уверены, что не потеряете своих изменений. Если вы действительно хотите использовать уже существующий рабочий каталог, то это возможно с помощью хирургического вмешательства в файлы `CVS/Repository'. Смотрите section Как данные хранятся в рабочем каталоге за дополнительной информацией о файлах `CVS/Repository' и `CVS/Root', но если вы не уверены, то, наверное, лучше не пытаться.
Рабочая копия исходных текстов и репозиторий могут быть на разных
машинах. Использование CVS таким образом известно как режим
клиент/сервер. Вы выполняете CVS-клиент на
машине, на которой смонтирован ваш рабочий каталог, и говорите
ему общаться с машиной, на которой смонтирован репозиторий, с
CVS-сервером. Вообще использование сетевого
репозитория похоже на использование локального, только формат
имени репозитория таков:
:метод:пользователь@машина:/путь/к/репозиторию
Детали зависят от того, как вы соединяетесь с сервером.
Если метод не указан, а имя репозитория содержит `:',
то метод по умолчанию -- ext или server, в
зависимости от платформы; оба метода описаны в section Соединение с помощью rsh.
Простой ответ: требования к серверу умеренны -- если дерево каталогов не очень большое, и активность не слишком высока, то подойдет машина с 32Mb памяти или даже меньше.
В реальной жизни, конечно, все сложнее. Оценка пикового использования памяти достаточна, чтобы оценить общие требования. Здесь документированы две такие области максимального потребления памяти; все остальные по сравнению с ними незначительны (если вы обнаружите, что это не так, дайте нам знать, как описано в section Что делать с ошибками в CVS и этом руководстве?, чтобы мы обновили документацию.
Первая область большого потребления памяти -- извлечения больших рабочих каталогов. Сервер состоит из двух процессов на каждого обслуживаемого клиента. Потребление памяти дочерним процессом должно быть невелико. Родительский процесс же, особенно когда сетевые соединения медленны, может вырасти до размеров, чуть больших размера исходных тестов, или до двух мегабайт, смотря что больше.
Умножая размер каждого CVS-сервера на количество клиентов, которые вы ожидаете одновременно, вы оцените требуемый размер памяти у сервера. По большей части память, потребляемая родительским процессом, будет находиться в файле подкачки, а не в физической памяти.
Вторая область большого потребления памяти -- diff при
фиксировании изменений в больших файлах. Это требуется даже для
бинарных файлов. Можно предусмотреть использование примерно
десятикратного размера самого большого файла, который только
будет фиксироваться, хотя пятикратный размер будет вполне
адекватен. Например, если вы хотите фиксировать файл размером в
десять мегабайт, то в машине, на которой выполняется фиксирование
(сервер или локальная машина, на которой находится репозиторий),
должно быть сто мегабайт. Скорее всего, это будет файл подкачки,
а не физическая память. Так как эта память требуется на
непродолжительное время, то особенной нужды выделять память под
несколько одновременных фиксирований нет.
Потребление ресурсов для клиентской машины еще более умеренны -- любая машина, способная выполнять соответствующую операционную систему, будет пригодна.
Информация о требованиях к дисковому пространству находится в section Создание репозитория.
rsh
CVS использует протокол rsh для работы с сетевым
репозиторием, поэтому на сетевой машине должен быть создан файл
`.rhosts', позволяющий доступ данному пользователю.
Например, предположим, что вы пользователь `mozart' на
локальной машине `toe.example.com', а сервер находится на
`faun.example.com'. На машине `faun' поместите в файл
`.rhosts' в домашнем каталоге пользователя `bach'
следующее:
toe.example.com mozart
Потом протестируйте, что rsh работает, запустив
rsh -l bach faun.example.org 'echo $PATH'
Затем вам следует убедиться, что rsh найдет сервер.
Убедитесь, что путь, напечатанный в результате выполнения этого
примера содержит каталог, содержащий исполняемый файл `cvs',
который является серверной версией CVS. Вы можете
установить путь в `.bashrc', `.cshrc', и т. п., но не
в файлах `.login' или `.profile'. Можно также
установить переменную среды CVS_SERVER на клиентской
машине, чтобы указать, какой исполняемый файл вы хотите
использовать, например, `/usr/local/bin/cvs-1.6'.
Не требуется редактировать `inetd.conf', чтобы запустить CVS как демона.
Вы можете использовать в CVSROOT два метода доступа для
rsh. :server: задает использование внутреннего
клиента rsh, который поддерживается только в некоторых
портах CVS. :ext: указывает внешнюю программу
rsh. По умолчанию это rsh, но вы можете установить
переменную среды CVS_RSH, чтобы выполнять другую
программу, которая может соединиться с сервером (например,
remsh на HP-UX 9, потому что rsh немного
отличается. Эта программа должна уметь пересылать данные с
сервера и на сервер, не изменяя их; например, rsh из
Windows NT не подходит, потому что он транслирует CR-LF в LF.
Порт CVS для OS/2 содержит хэк, который передает rsh
параметр `-b', чтобы обойти это,но так как это может
привести к проблемам с программами, не являющимися стандартным
rsh, это может быть изменено в будущем. Если вы
устанавливаете CVS_RSH в ssh или какую-нибудь
другую замену rsh, то инструкции по настройке
`.rhosts', скорее всего, неприменимы, поэтому обратитесь к
документации по соответствующей программе.
Продолжая наш пример, предположив, что вы хотите обратиться к
модулю `foo' в репозитории `/usr/local/cvsroot' на
машине `faun.example.org', вы набираете:
cvs -d :ext:bach@faun.example.org:/usr/local/cvsroot checkout foo
(Можно не писать `bach@', если имена пользователей совпадают на локальной и сетевой машинах.)
Клиент CVS также может соединяться с сервером, используя
протокол с паролем. Это особенно полезно, когда использование
rsh неосуществимо, (например, если сервер находится за
файерволлом), и Kerberos также недоступен.
Чтобы использовать этот метод, необходима некоторая настройка как сервера, так и клиентов.
Во-первых, вы, вероятно, хотите усилить права доступа к каталогам `$CVSROOT' и `$CVSROOT/CVSROOT'. См. section Прямое соединение с парольной аутентификацией за дополнительными деталями.
На стороне сервера следует редактировать файл
`/etc/inetd.conf', чтобы inetd знал, что следует
выполнять команду cvs pserver, когда кто-либо пытается
соединиться с соответствующим портом. По умолчанию номер порта
--- 2401; это значение можно изменить, если перед компиляцией
установить параметр CVS_AUTH_PORT в другое значение.
Если ваш inetd позволяет использование номеров портов в
`/etc/inetd.conf', то можно использовать такую строку:
2401 stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/usr/cvsroot pserver
Вы можете также использовать ключ командной строки `-T', чтобы указать временный каталог.
Ключ командной строки `--allow-root' задает разрешенный каталог CVSROOT. Клиенты, пытающиеся использовать другой каталог, не смогут соединиться. Если вы хотите разрешить доступ к нескольким каталогам CVSROOT, повторите эту опцию.
Если ваш inetd требует текстовых имен сервисов вместо
номеров портов, поместите эту строчку в `/etc/services':
cvspserver 2401/tcp
и напишите cvspserver вместо 2401 в файле
`/etc/inetd.conf'.
После всего этого перезапустите inetd или заставьте его
перечитать файлы конфигурации. В случае проблем с настройкой
смотрите section Ошибки при установке соединения с CVS-сервером.
Так как клиент хранит и пересылает пароли практически открытым
тестом (см. section Прямое соединение с парольной аутентификацией), то может
использоваться отдельный файл паролей для CVS, чтобы
пользователи не раскрывали своих обычных паролей при доступе к
репозиторию. Этот файл -- `$CVSROOT/CVSROOT/passwd'
(see section Административные файлы). Его формат похож на
`/etc/passwd', но он имеет только два или три поля: имя
пользователя, пароль и необязательное имя пользователя для
использования сервером. Например:
bach:ULtgRLXo7NRxs
cwang:1sOp854gDF3DY
Пароль шифруется стандартной функцией UNIX crypt(),
поэтому можно просто перенести пароль из обычного файла
`passwd'.
При парольной аутентификации сервер сначала проверяет, находится
ли пользователь в файле `CVSROOT/passwd'. Если нет, или
файл `CVSROOT/passwd' не существует, то сервер пытается
проверить пароль, используя системную процедуру проверки
пользователя (это может быть запрещено, установив
SystemAuth=no в файле конфигурации, see section Файл конфигурации CVSROOT/config).
При использовании файла `CVSROOT/passwd' сервер выполняется
с правами пользователя, указанного в третьем поле соответствующей
строки, или, если третьего поля нет, то в первом (таким образом
CVS позволяет использовать ненастоящие имена пользователей,
если в `CVSROOT/passwd' заданы соответствующие им настоящие
системные имена. В любом случае, CVS не получит
дополнительных прав, кроме тех, что уже имеет пользователь.
С помощью файла `CVSROOT/passwd' можно также отобразить
пользователей CVS в имена пользователей машины, добавив
двоеточие и системное имя пользователя после пароля. Например:
cvs:ULtgRLXo7NRxs:kfogel
generic:1sOp854gDF3DY:spwang
anyone:1sOp854gDF3DY:spwang
Таким образом, пользователи, обращающиеся по сети к репозиторию
на faun.example.org, используя команду
cvs -d :pserver:cvs@faun.example.org:/usr/local/cvsroot checkout foo
будут работать с сервером, который имеет права пользователя
kfogel, если, конечно, они успешно аутентифицировались.
При этом сетевые пользователи не знают системный пароль
пользователя kfogel, потому что файл `CVSROOT/passwd'
может содержать другой пароль, используемый только
CVS-сервером. Как показано в вышеприведенном примере, можно
отображать разные имена пользователей CVS в единственного
системного пользователя.
Эта возможность создана, чтобы позволить доступ к репозиторию без полного доступа к системе (в частности, см. section Доступ к репозиторию только для чтения); однако, смотри также section Прямое соединение с парольной аутентификацией. Любой доступ к репозиторию, скорее всего, подразумевает также некоторый доступ к системе вообще.
В настоящее время единственный способ поместить пароль в
`CVSROOT/passwd' -- это вырезать его откуда-нибудь еще.
Когда-нибудь появится команда cvs passwd. В отличие от
других файлов в `$CVSROOT/CVSROOT', вы редактируете файл
`CVSROOT/passwd' напрямую, а не с помощью CVS.
Перед соединением с сервером клиент должен
зарегистрироваться с помощью команды cvs login.
При регистрации на сервере проверяется пароль, который затем
сохраняется для дальнейшего общения с сервером. Команда
cvs login должна знать имя пользователя, имя машины с
сервером и полный путь к репозиторию. Эту информацию CVS
получает из ключа командной строки `-d' и переменной
окружения CVSROOT.
cvs login -- это интерактивная команда, она спрашивает
пароль:
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login
CVS password:
Пароль проверяется на сервере, если он правильный, то команда
login завершается успешно, в противном случае она жалуется
на неверный пароль и завершается с ошибкой.
После регистрации вы можете заставить CVS соединяться
напрямую с сервером, используя при этом сохраненный пароль.
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout foo
Обязательно надо указать `:pserver:', в противном случае
CVS будет считать, что ему следует использовать rsh
для соединения с сервером (see section Соединение с помощью rsh).
(Когда вы получили рабочий каталог и выполняете команды CVS
внутри него, больше не требуется явно указывать репозиторий,
потому что CVS запоминает его в подкаталоге `CVS' в
рабочем каталоге.)
Пароли обычно хранятся в файле `$HOME/.cvspass'. У него читабельный формат, но не следует редактировать его, если вы не знаете точно, что вы делаете. Пароли не хранятся открытым текстом, а слегка шифруются, чтобы защититься от нечаянного нарушения безопасности (например, системный администратор, случайно заглянувший внутрь этого файла).
Пароль текущего сетевого репозитория удаляется из
CVS_PASSFILE при использовании команды cvs logout.
С помощью переменной окружения CVS_PASSFILE можно
переназначить файл, в котором хранятся пароли. Если вы
используете эту переменную, убедитесь, что вы установили ее
перед использование cvs login. Если вы установите
ее после выполнения cvs login, то последующие команды
CVS не смогут найти пароля для пересылки его на сервер.
Пароли хранятся на стороне клиента тривиально зашифрованным открытым текстом и передаются точно так же. Такое шифрование используется только для предотвращения нечаянного подсматривания пароля (например, системный администратор, случайно заглянувший в файл) и не предотвращает даже самые тривиальные атаки.
Отдельный файл паролей CVS (see section Настройка сервера для парольной аутентификации) позволяет использовать для доступа к репозиторию пароль, отличающийся от пароля для доступа к машине. С другой стороны, если пользователь получил доступ к репозиторию для чтения и записи, он может различными способами выполнять программы на сервере. Таким образом, доступ к репозиторию означает также довольно широкий диапазон другого доступа к системе. Можно было бы модифицировать CVS, чтобы предотвратить это, но до сих пор никто этого не сделал. Более того, могут быть другие способы, которыми люди, имеющие доступ к репозиторию, получат доступ к системе; никто не производил тщательного аудита.
Заметьте, что из-за того, что каталог `$CVSROOT/CVSROOT' содержит `passwd' и прочие файлы, использующиеся в целях безопасности, нужно следить за правами доступа к этому каталогу так же хорошо, как из правами доступа к `/etc'. То же самое применимо к самому каталогу `$CVSROOT' и любому каталогу, находящему в нем. Кто угодно, получив доступ для записи в этот каталог, сможет стать любым пользователем в системе. Заметьте, что эти права доступа обычно строже при использовании pserver.
Вообще, любой, кто получает пароль, получает доступ к репозиторию, и, до некоторой степени, доступ к самой системе. Пароль доступен всем, кто может перехватить сетевые пакеты или прочитать защищенный (принадлежащий пользователю) файл. Если вы хотите настоящей безопасности, используйте Kerberos.
GSSAPI -- это общий интерфейс к системам сетевой безопасности, таким как Kerberos 5.
Если у вас есть рабочая библиотека GSSAPI, то ваш CVS может
совершать TCP-соединения с сервером, аутентифицируясь с
помощью GSSAPI. Для этого CVS нужно скомпилировать с
поддержкой GSSAPI; при конфигурировании CVS пытается
определить, наличествуют ли в системе библиотеки GSSAPI,
использующии Kerberos версии 5. Вы также можете дать
configure флаг --with-gssapi.
Соединение аутентифицируется, используя GSSAPO, но сам поток
данных не аутентифицируется по умолчанию. Вы должны
использовать глобальный ключ командной строки -a, чтобы
запросить аутентификацию потока.
Передаваемые данные по умолчанию не шифруются. Как сервер,
так и клиент могут быть скомпилированы с поддержкой шифрования;
используйте ключ командной строки configure
--enable-encrypt. Для включения шифрования используйте
ключ командной строки -x.
Соединения GSSAPI обрабатываются на стороне сервера тем же
сервером, что производит парольную аутентификацию; смотри
section Настройка сервера для парольной аутентификации. Если вы используете,
например, Kerberos, обеспечивающий хорошую аутентификацию, вы,
вероятно захочете также устранить возможность аутентифицироваться
с использованием паролей открытым текстом. Для этого создайте
пустой файл `CVSROOT/passwd' и поместите
SystemAuth=no в файл конфигурации `config'.
Сервер GSSAPI использует principal name cvs/имя-машины, где имя-машины -- это каноническое имя сервера. Вам потребуется настроить ваш механизм GSSAPI.
Для соединения с использованием GSSAPI, используйте
`:gserver:'. Например,
cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo
Самый простой способ использования Kerberos -- это kerberos
rsh, что описано в section Соединение с помощью rsh.
Основной недостаток использования rsh -- тот, что все данные
должны проходить сквозь дополнительные программы, что замедляет
работу. Поэтому если у вас установлен Kerberos, вам следует
использовать прямые TCP-соединения, аутентифицируясь с
помощью Kerberos.
Эта глава относится к системе Kerberos версии 4. Kerberos версии 5 поддерживается посредством общего интерфейса сетевой безопасности GSSAPI, как описано в предыдущей главе.
CVS должен быть скомпилирован с поддержкой kerberos; при
конфигурировании CVS пытается определить, какая версия
Kerberos присутствует на машине. Вы можете также использовать
ключ командной строки configure --with-krb4.
Пересылаемые данные по умолчанию не шифруются. Как
клиент, так и сервер должны быть скомпилированы с использованием
шифрования; используйте ключ командной строки configure
--enable-encryption. Для включения шифрования используйте
глобальный ключ командной строки -x.
На сервере требуется отредактировать /etc/inetd.conf,
чтобы запустить cvs kserver. Клиент по умолчанию
использует порт 1999; если вы хотите использовать другой порт,
задайте его на клиентской машине в переменной окружения
CVS_CLIENT_PORT.
Когда вы захотите использовать CVS, сначала, как обычно,
получите билет (kinit); этот билет должен позволять вам
зарегистрироваться на сервере. Затем
cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo
Предыдущие версии CVS могли в случае неудачи использовать
соединение с помощью rsh; текущие версии так не делают.
cvs server для соединения
Этот метод доступа позволяет вам соединяться с репозиторием,
находящимся на локальном диске, используя сетевой протокол.
Другими словами, он делает то же самое, что и :local:, но
при этом с особенностями и ошибками, существующими у сетевого, а
нее локального CVS.
Для каждодневных операций вы, скорее всего, предпочтете
:local: или :fork:, в зависимости от ваших
предпочтений. Конечно, :fork: особенно полезен при
тестировании и отладке cvs и сетевого протокола. Точнее,
мы избавляемся от необходимости настройки сети, таймаутов,
проблем с аутентификацией, свойственных сетевому доступа, но при
этом пользуемся собственно сетевым протоколом.
Чтобы соединиться, используя метод доступа :fork:,
добавьте его к имени локального репозитория, например:
cvs -d :fork:/usr/local/cvsroot checkout foo
Как и при использовании :ext:, сервер по умолчанию
называется `cvs'. Если установлена переменная окружения
CVS_SERVER, используется ее значение.
Существует возможность предоставить публичный доступ к репозиторию только для чтения, используя сервер парольной аутентификации (see section Прямое соединение с парольной аутентификацией). (Прочие методы доступа не имеют явной поддержки для доступа только для чтения, потому что все эти методы подразумевают регистрацию на машине с репозиторием, и поэтому пользователь может делать все, что позволяют ему права доступа к файлам.)
Пользователь, имеющий доступ к репозиторию только для чтения, может выполнять все команды CVS, не изменяющие репозиторий, за исключением определенных "административных" файлов (таких, как файлы блокировок и файл истории). Может потребоваться использовать эту возможность совместно с возможностью использования псевдонимов пользователей (see section Настройка сервера для парольной аутентификации).
В отличие от предыдущих версий CVS, пользователи с доступом только для чтения должны быть способны только читать репозиторий, но не выполнять программы на сервере или другим способом получать ненужные уровни доступа. Говоря точнее, закрыты все ранее известные дыры в безопасности. Так как эта возможность появилась недавно и не подвергалась исчерпывающему анализу безопасности, вы должны действовать с максимально необходимой осторожностью.
Есть два способа указать доступ пользователя только для чтения: включающий и исключающий.
Включающий способ означает, что пользователь явно
указывается в файле `$CVSROOT/CVSROOT/readers', в котором
просто перечисляются "в столбик" пользователи. Вот пример:
melissa
splotnik
jrandom
(Не забудьте символ новой строки в конце файла.)
Исключающий способ означает, что все, кто имеет доступ к репозиторию для записи, перечисляются в файле `$CVSROOT/CVSROOT/writers'. Если этот файл существует, то все пользователи, не упомянутые в нем, получают доступ только для чтения (конечно, даже пользователи только для чтения должны быть упомянуты в файле `CVSROOT/passwd'). Файл `writers' имеет тот же формат, что и файл `readers'.
Замечание: если ваш файл `CVSROOT/passwd' отображает пользователей CVS в системных пользователей (see section Настройка сервера для парольной аутентификации), убедитесь, что вы предоставляете или не предоставляете доступ только для чтения пользователям CVS, а не системным пользователям. Это означает, что в файлах `readers' и `writers' должны находиться пользователи CVS, которые могут не совпадать с системными пользователями.
Вот полное описание поведения сервера, принимающему решение, какой тип доступа предоставить:
Если файл `readers' существует, и данный пользователь не упомянут в нем, он получает доступ только для чтения. Если существует файл `writers', и этот пользователь НЕ упомянут в нем, то он также получает доступ только для чтения (это так даже если файл `readers' существует, но пользователь не упомянут в нем). В противном случае пользователь получает полный доступ для чтения и записи.
Конечно, возможен конфликт, если пользователь упомянут в обоих файлах. Такой конфликт разрешается консервативно и такой пользователь получает доступ только для чтения.
В процессе работы CVS-сервер создает временные каталоги.
Они называются
cvs-servpid
где pid -- это номер процесса сервера. Они находятся в
каталоге, указанном в переменной окружения TMPDIR
(see section Все переменные окружения, используемые в CVS), ключом командной строки `-T'
или в `/tmp' по умолчанию.
В большинстве случаев сервер сам удалит временный каталог в конце работы. В некоторых случаях сервер может завершиться, не удалив свой временный каталог, например:
В таких случаях вы должны вручную удалить каталоги `cvs-servpid'. Если нет сервера с номером процесса pid, то сделать это можно совершенно безопасно.
Go to the first, previous, next, last section, table of contents.