Содержание, Следующая страница
|
CVS - документация v 1.0 |
В репозитории 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, несколько отличаются от стандартного формата. Волшебные ветки -- самое большое отличие; see section Волшебные номера веток. Имена меток, которые позволяет использовать CVS, являются подмножеством тех, что позволены в RCS; see section Метки ревизий.
Все файлы `,v' создаются с правами "только для чтения", и вам не следует изменять эти права доступа. Каталоги в репозитории должны быть доступны для записи тем, кому разрешено изменять файлы в каждом каталоге. Это обычно означает, что вам нужно создать группу пользователей UNIX (см. страницу руководства group(5)), состоящую из лиц, участвующих в создании проекта, и настроить репозиторий так, чтобы эта группа была владельцем каталога с проектом.
Это означает, что ограничивать доступ к файлам можно только на уровне каталога.
Заметьте, что пользователи должны иметь права на запись в каталог и для извлечения файлов, потому что CVS должна создать файлы блокировки (see section Совместный доступ нескольких разработчиков к CVS).
Заметьте также, что пользователи должны иметь права на запись в файл `CVSROOT/val-tags'. CVS использует этот файл, чтобы отслеживать, какие метки разрешены (этот файл иногда обновляется, когда используются и когда создаются метки).
Каждый RCS-файл принадлежит пользователю, который последним зафиксировал изменения в этот файл. Этот факт не столь важен, главное -- кто владелец каталога.
CVS пытается установить адекватные права доступа к файлам
для новых каталогов, которые создаются в дереве, но если вам
требуется, чтобы новый каталог имел права доступа, отличающиеся
от его родительского каталога, вы должны задать это вручную.
Если вы установите переменную окружения CVSUMASK, то она
будет задавать, какие права доступа к файлам CVS использует
при создании каталогов и/или файлов в репозитории.
CVSUMASK не влияет на права доступа к файлам в рабочем
каталоге; такие файлы имеют права, обычные для новых файлов,
разве что только иногда CVS создает их с правами только для
чтения (See section Слежение за чужими исходными текстами. See section Глобальные ключи командной строки, где описан ключ `-r'; See section Все переменные окружения, используемые в CVS,
в которой описана переменная CVSREAD).
Заметьте, что при использовании клиент-серверного CVS
(see section Сетевые репозитории) не существует нормального способа
установить CVSUMASK; установка его на клиентской машине не
играет роли. Если вы соединяетесь с помощью rsh, то
можете устанавливать CVSUMASK в файле `.bashrc' или
`.cshrc', как описано в документации на вашу операционную
систему. Это поведение может измениться в будущей версии
CVS; не полагайтесь на то, что установка CVSUMASK на
клиентской машине не играет роли.
При использовании сервера парольной аутентификации
(`pserver') обычно требуются гораздо более жесткие права
доступа к каталогу $CVSROOT и каталогам, находящимся в
нём; see section Настройка сервера для парольной аутентификации.
Некоторые операционные системы позволяют определенным программам выполнять операции, которые не может выполнять тот, кто вызывает эти программы. Таковы, например, возможности setuid или setgid в UNIX или установленные образы в VMS. CVS не разрабатывался, чтобы использовать такие возможности, и поэтому попытки установить CVS таким образом обеспечат защиту только лишь от случайных ошибок; те, кто желает обойти защиту, смогут это сделать и, в зависимости от конкретных условий, смогут получить доступ еще куда-либо помимо CVS. Вы можете попробовать использовать 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 за дополнительной информацией. В будущем в этом каталоге могут оказать другие дополнительные файлы, поэтому сегодняшние реализации должны игнорировать неизвестные файлы.
Это поведение реализовано только в версиях @cvsver{1.7} и выше, see section Использование слежений со старыми версиями CVS.
Видимое пользователем поведение блокировок CVS описано в section Совместный доступ нескольких разработчиков к CVS. Эта глава ориентирована на людей, пишущих утилиты, обращающиеся к репозиторию CVS, не конфликтуя при этом с другими программами, обращающимися к тому же репозиторию. Если вы запутаетесь в описываемых здесь концепциях, как то блокировка чтения, блокировка записи и мертвая блокировка, то обратитесь к литературе по операционным системам или базам данных.
Файлы в репозитории, чьи имена начинаются с `#cvs.rfl' --- это блокировки чтения. Файлы, чьи имена начинаются с `#cvs.wfl' -- это блокировки записи. Старые версии CVS (до @cvsver{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, где находится репозиторий.
Серьезным преимуществом нескольких репозиториев является то, что они могут находиться на различных серверах. При использовании @cvsver{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') в каждом каталоге репозитория. See section Совместный доступ нескольких разработчиков к CVS, где приводится дополнительная информация о блокировках CVS. Даже учитывая вышесказанное, если вы просто скопируете файлы, ничего особенно страшного не произойдет. Однако, при восстановлении из резервной копии репозиторий может находиться в неустойчивом состоянии, что, впрочем, нетрудно исправить вручную.
Когда вы восстанавливаете репозиторий из резервной копии, предполагая, что репозиторий изменился с момента последнего резервного копирования, рабочие каталоги, которые не пострадали, могут ссылаться на ревизии, не существующие более в репозитории. Попытка выполнения CVS в таких каталогах приведет к сообщению об ошибке. Один из способов вернуть все изменения в репозиторий таков:
cvs update и cvs diff, чтобы выяснить, что
изменилось, а затем зафиксируйте изменения в репозиторий.
Точно так же, как и в случае с резервным копированием файлов, перемещение репозитория с места на место сводится к перемещению набора файлов.
Основная вещь, которую нужно учитывать -- это то, что рабочие каталоги ссылаются на репозиторий. Самый простой способ справиться с этим -- получить свежий рабочий каталог после перемещения. Конечно, вам следует сначала убедиться, что старый рабочий каталог был зафиксирован перед перемещением, или вы уверены, что не потеряете своих изменений. Если вы действительно хотите использовать уже существующий рабочий каталог, то это возможно с помощью хирургического вмешательства в файлы `CVS/Repository'. See 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'. See 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 -f --allow-root=/usr/cvsroot pserver
Вы можете также использовать ключ командной строки `-T', чтобы указать временный каталог.
Ключ командной строки `--allow-root' задает разрешенный каталог CVSROOT. Клиенты, пытающиеся использовать другой каталог, не смогут соединиться. Если вы хотите разрешить доступ к нескольким каталогам CVSROOT, повторите эту опцию.
Если ваш inetd требует текстовых имен сервисов вместо
номеров портов, поместите эту строчку в `/etc/services':
cvspserver 2401/tcp
и напишите cvspserver вместо 2401 в файле
`/etc/inetd.conf'.
После всего этого перезапустите inetd или заставьте его
перечитать файлы конфигурации. В случае проблем с настройкой
смотрите section Ошибки при установке соединения с CVS-сервером.
Так как клиент хранит и пересылает пароли практически открытым тестом (See section Прямое соединение с парольной аутентификацией, где описаны детали), то может использоваться отдельный файл паролей для CVS, чтобы пользователи не раскрывали своих обычных паролей при доступе к репозиторию. Этот файл -- `$CVSROOT/CVSROOT/passwd' (see section Административные файлы). В этом файле используется обычный формат строк, разделенных двоеточиями, типа того, что используется в файле `/etc/passwd' в Unix-системах. В этом файле несколько полей: имя пользователя CVS, необязательный пароль и необязательное имя системного пользователя, на правах которого будет работать CVS после успешной аутентификации. Вот пример файла `passwd', в котором находится пять строк:
anonymous: bach:ULtgRLXo7NRxs spwang:1sOp854gDF3DY melissa:tGX1fS8sun6rY:pubcvs qproj:XR4EZcEs0szik:pubcvs
(Пароли шифруются стандартной функцией UNIX crypt(),
поэтому можно просто перенести пароль из обычного файла
`/etc/passwd'.
Первая строка в этом примере предоставляет доступ любому
CVS-клиенту, пытающемуся аутентифицироваться с именем
anonymous и любым паролем, включая пустой пароль. (Это
обычное решение для машин, предоставляющих анонимный доступ
только для чтения; информация о предоставлении доступа только для
чтения находится в See section Доступ к репозиторию только для чтения.
Вторая и третья строки предоставляют доступ пользователям
bach и spwang, если они знают соответствующий
пароль.
Четвертая строка предоставляет доступ пользователю
melissa, если она знает правильный пароль. При этом сама
серверная программа CVS на самом деле выполняется на правах
системного пользователя pubcvs. Таким образом, в системе
не требуется заводить пользователя melissa, но
обязательно должен быть пользователь pubcvs.
Пятая строка демонстрирует, что системные пользователи могут
использоваться совместно: любой клиент, который успешно
аутентифицируется как qproj, будет работать на правах
системного пользователя pubcvs, так же, как и
melissa. Таким образом, вы можете создать единственного
общего системного пользователя для каждого проекта в вашем
репозитории, и предоставить каждому разработчику свою собственную
строку в файле `$CVSROOT/CVSROOT/passwd'. Имя
CVS-пользователя в каждой строке будет разным, но имя
системного пользователя будет одним и тем же. Причина, по
которой нужно иметь разные имена пользователей CVS в том,
что все действия CVS будут журналироваться под этими
именами: когда melissa фиксирует изменения в проекте, эта
фиксация записывается в историю проекта под именем
melissa, а не pubcvs. Причина, по которой следует
иметь одиночного системного пользователя в том, что вы сможете
задать права доступа к соответствующим каталогам репозитория так,
что только этот системный пользователь будет иметь права на
запись.
Если в строке присутствует поле с системным пользователем, то все команды CVS выполняются на правах этого пользователя; если системное имя не задано, то CVS просто берет имя пользователя CVS в качестве имени системного пользователя, и работает на его правах. В любом случае, если в системе нет такого пользователя, то CVS-сервер откажется работать, даже если клиент сказал правильный пароль.
Пароль и имя системного пользователя могут отсутствовать (при отсутствии последнего не следует писать двоеточие, которое служит разделителем полей). Например, файл `$CVSROOT/CVSROOT/passwd' может выглядеть так:
anonymous::pubcvs fish:rKa5jzULzmhOo:kfogel sussman:1sOp854gDF3DY
Когда пароль пропущен или пустой, то аутентификация произойдет успешно с любым паролем, включая пустую строку. Однако, двоеточие после имени пользователя CVS всегда обязательно, даже если пароль пуст.
CVS также может использовать стандартную системную
аутентификацию. При парольной аутентификации сервер сначала
проверяет наличие пользователя в файле
`$CVSROOT/CVSROOT/passwd'. Если пользователь обнаружен в
этом файле, то соответствующая строка будет использована для
аутентификации, как описано выше. Если же пользователь не
найден, или файле `passwd' не существует, то сервер пытается
аутентифицировать пользователя с помощью системных процедур (это
"резервное" поведение может быть запрещено, установив
SystemAuth=no в файле `config', see section Файл конфигурации CVSROOT/config). Помните, однако, что использование системной
аутентификации может увеличить риск нарушения безопасности:
операции CVS будут аутентифицироваться его обычным паролем,
который будет передаваться по сети в текстовом виде.
См. section Вопросы безопасности при парольной аутентификации, где описаны
детали.
В настоящее время единственный способ поместить пароль в
`CVSROOT/passwd' -- это вырезать его откуда-нибудь еще.
Когда-нибудь появится команда cvs passwd.
В отличие от большинства файлов в `$CVSROOT/CVSROOT', обычно практикуется редактирование файла `passwd' прямо в репозитории, без использования CVS. Это из-за риска безопасности, связанного с извлечением этого файла в чью-нибудь рабочую копию. Если вы хотите, чтобы файл `passwd' извлекался вместе с остальными файлами в `$CVSROOT/CVSROOT', см. See section Как в каталоге CVSROOT хранятся файлы.
Для того, чтобы выполнить команду CVS в сетевом репозитории
с помощью сервера парольной аутентификации, нужно задать
протокол pserver, имя пользователя, машину, на которой
находится репозиторий, и путь к репозиторию. Например:
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout someproj
или
CVSROOT=:pserver:bach@faun.example.org:/usr/local/cvsroot cvs checkout someproj
Однако, если только вы не работаете с публичным репозиторием (то
есть таким, где имя определенного пользователя не требует
использования пароля), вам сначала потребуется войти в
систему. При входе в систему проверяется ваш пароль. Это
происходит при выполнении команды login, которая
спрашивает у вас пароль:
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login CVS password: _
После того, как вы ввели пароль, CVS проверяет этот пароль
на сервере. Если результат положителен, то комбинация имени
пользователя, машины, пути к репозиторию и пароля сохраняются в
специальном файле, чтобы при дальнейшей работе с этим
репозиторием от вас не требовалось запускать cvs login.
(Если результат проверки отрицателен, CVS пожалуется, что
пароль неверен, и, естественно, он не будет сохранен.)
Пароли обычно хранятся в файле `$HOME/.cvspass'. Этот файл можно прочитать глазами, и, до какой-то степени, можно отредактировать руками. Заметьте, впрочем, что пароли не хранятся в совсем открытом виде: они тривиально закодированы, чтобы защититься от нечаянного подсматривания (например, системным администратором или кем-либо другим, не настроенным враждебно).
Изменить место расположения этого файла можно, установив
переменную окружения CVS_PASSFILE. При использовании этой
переменной не забудьте установить её перед использованием
cvs login. Если вы этого не сделаете, то последующие
команды CVS не смогут найти паролей для отправки на сервер.
После того, как вы вошли в систему, все команды CVS, использующие этот сетевой репозиторий и имя пользователя, смогут аутентифицироваться, используя этот сохраненный пароль. Поэтому, например:
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout foo
будет работать без дополнительных вопросов (если только пароль не
изменится на сервере, в этому случае вам нужно ещё раз выполнить
cvs login).
Заметьте, что если забыть про `:pserver:' в имени
репозитория, то CVS будет считать, что вы собираетесь
использовать rsh (see section Соединение с помощью rsh).
Конечно же, после того, как вы извлекли рабочую копию, то можно не задавать имя репозитория при работе с ней, потому что CVS может и сама взять это имя из каталога `CVS/'.
Пароль к определенному сетевому репозиторию можно удалить из
файла паролей с помощью команды cvs logout.
Пароли хранятся на стороне клиента тривиально зашифрованным открытым текстом и передаются точно так же. Такое шифрование используется только для предотвращения нечаянного подсматривания пароля (например, системный администратор, случайно заглянувший в файл) и не предотвращает даже самые тривиальные атаки.
Отдельный файл паролей 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.
Соединение аутентифицируется, используя GSSAPI, но сам поток
данных не аутентифицируется по умолчанию. Вы должны
использовать глобальный ключ командной строки -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, то сделать это можно совершенно безопасно.