Статья: Введение в CVS Конспект первого дня двухдневного курса по CVS
...введите описание httpc...
$ ls
CVS Makefile README httpc.c poll-server
$ cvs update
cvs update: Updating .
? README --- CVS еще не знает об этом файле
$ cvs add README
cvs add: scheduling file `README' for addition
cvs add: use 'cvs commit' to add this file permanently
$ cvs update --- что же теперь думает CVS?
cvs update: Updating .
A README --- Файл помечен как добавленный
$ cvs commit README
... CVS просит вас ввести журнальную запись...
RCS file: /u/jimb/cvs-class/rep/httpc/README,v
done
Checking in README;
/u/src/master/httpc/README,v <-- README
initial revision: 1.1
done
$
CVS обращается с удаленными файлами почти так же. Если вы удалите файл и выполните `cvs update', CVS не считает, что вы намереваетесь удалить файл из проекта. Вместо этого он поступает милосерднее -- он восстанавливает последнюю сохраненную в репозитории версию файла и маркирует его флагом U, точно так же, как и любой другое обновление. (Это означает, что если вы хотите отменить изменения файла в рабочем каталоге, вы можете просто удалить его и позволить команде `cvs update' создать его заново.)
Чтобы удалить файл из проекта, вы должны сначала удалить его,а потом использовать команду `cvs rm', чтобы пометить его для удаления. При следующем запуске команда `cvs commit' удалит файл из репозитория. Фиксирование файла, маркированного с помощью `cvs rm' не уничтожает историю этого файла -- к ней просто добавляется еще одна редакция --- "не существует". В репозитории по прежнему хранятся все записи об этом файле, и к ним можно обращаться по желанию -- например, с помощью `cvsdiff' или `cvslog'.
Для переименования файла существует несколько стратегий; самая простая --- переименовать файл в рабочем каталоге, затем выполнить `cvs rm' со старым именем и `cvs add' с новым. Недостаток этого подхода в том, что журнальные записи о содержимом старого файла не переносятся в новый файл. Другие стратегии позволяют избежать этого, но зато доставляют другие, более странные проблемы.
Вы можете добавлять каталоги точно также, как и обычные файлы.
Написание хороших журнальных записей Если можно использовать `cvs diff', чтобы получить точное содержание любого изменения, то зачем тогда придумывать еще журнальную запись о нем? Очевидно, что журнальные записи короче, чем тексты изменений, и позволяют читателю получить общее понимание изменения без необходимости углубляться в детали.
Однако же, хорошая запись в журнале описывает причину, по которой было сделано изменение. Например, плохая журнальная запись для редакции 1.7 может звучать как "Преобразовать `t' к нижнему регистру". Это правильно, но бесполезно - `cvs diff' предоставляет точно ту же информацию, и гораздо яснее. Гораздо лучшей журнальной записью было бы "Сделать эту проверку независящей от регистра", потому что это гораздо яснее описывает причину любому, кто понимает, что происходит в коде - клиенты HTTP должны игнорировать регистр букв при анализе заголовков ответа от сервера.
Обработка конфликтов Как уже упоминалось, команда `cvs update' объединяет изменения, сделанные другими разработчиками, с исходными текстами в вашем рабочем каталоге. Если вы отредактировали файл одновременно с кем-то другим, CVS объединит ваши изменения.
Довольно легко представить себе, как работает объединение, если изменения были совершены в разных участках файла, но что если вы оба изменили одну и ту же строку? CVS называет эту ситуацию конфликт и предоставляет вам самому разобраться с ним.