Читать «Управление исходными текстами. Часть 1. Краткое руководство по CVS» онлайн - страница 5

:local:c:/cvs/repository/

или так (для UNIX):

:local:/usr/local/cvsroot

ПРЕДУПРЕЖДЕНИЕ. Обратите внимание, что для Windows слэши всё равно должны быть прямыми, а не обратными, как это принято в самой операционной системе. Кроме того, в CVS имена файлов чувствительны к регистру символов (case sensitive), тогда как Windows игнорирует регистр. Это может привести к проблемам, если у вас в репозитории находятся файлы File.h и file.h. Старайтесь использовать нижний регистр для имен файлов при работе с Windows.

Примеры CVSROOT с комментариями:

:pserver:[email protected]:/cvsroot

 Метод доступа pserver – простая авторизация паролем

 Сервер находится по адресу megasoft.com

 Имя пользователя “user”

 Локальный путь на сервере к репозиторию - /cvsroot

 Пользователь должен выполнить команду login перед доступом к серверу

:sspi:dev-server:/projects

 Метод доступа sspi – использование авторизации в Windows-домене

 Сервер – dev-server в текущем домене

 Имя пользователя – текущий пользователь Windows

 Условное имя репозитория на сервере – projects

:method:[[user][:password]@]hostname[:[port]]/path/to/repository

 Общий вид для удалённого репозитория

 Использовать открытый пароль в CVSROOT крайне не рекомендуется, лучше пользоваться командой cvs login

Совмещение и обновление

CVS всегда помнит, какие редакции у вас находятся в рабочем каталоге. Для изменённых файлов он помнит, какие редакции у них были до того, как вы начали изменять эти файлы. Это необходимо, чтобы правильно совместить несколько изменений, произошедших с файлом одновременно.

Предположим, что два разработчика одновременно начали работать над одним и тем же файлом, и в момент начала этого процесса в репозитории была редакция 1.1. По истечении определенного времени мы имеем в репозитории редакцию 1.1 и в двух рабочих каталогах изменения к этой редакции. Предположим также, что работа в каталоге №2 закончена и изменения отправляются в репозиторий (детали этой операции мы рассмотрим в следующей части статьи). В репозитории появляется новая редакция файла и ей присваивается номер 1.2. В каталоге №2 тоже содержится редакция 1.2. Однако в каталоге №1 по-прежнему находятся изменения относительно редакции 1.1.

Рисунок 4.

Теперь, если мы захотим отправить изменения в репозиторий из рабочего каталога №1, система откажет нам в операции, поскольку каталог №1 устарел и сформировать редакцию 1.3 в репозитории невозможно. Поэтому каталог №1 необходимо сначала обновить, при этом произойдёт совмещение (merge) редакций. Иными словами, изменения от 1.1 до 1.2, имеющиеся в репозитории, будут применены к файлу в рабочем каталоге. При этом изменения, сделанные локально, не пропадают и, в результате, в рабочем каталоге оказывается редакция 1.2 с изменениями, сделанными локально. Теперь можно спокойно отправить файл в репозиторий и получить редакцию 1.3, в которой наличествуют изменения, сделанные в обоих рабочих каталогах. Для полного завершения картины мы должны обновить каталог №2 (там по-прежнему находится редакция 1.2) до редакции 1.3, имеющейся в репозитории.