Что такое CVS, и зачем это надо?

Необходимость в системе контроля версий появляется например тогда, когда в достаточно большом проекте некотороая ошибка проявляестя только через некоторое время после внесения изменений. С помощью CVS можно очень быстро и просто получить нужную версию файла и увидеть, что конкретно вызвало появление ошибки.

Превосходство CVS против обычного резервного копирования файлов после каждого изменения в том, что CVS сохраняет все версии в одном файле, добавляя только данные о внесенных изменениях.

Также CVS помогает при работе нескольких людей над одним проектом - она не позволяет изменять одновременно одну и ту же чать файла нескольким людям. При этом каждый отдельный разработчик работает только со своей копией файла, что не вызывает ошибок разделения доступа при одновременной работе нескольких разработчиков. CVS сама следит за объединением изменений.

Чего не может CVS

CVS следит за пересечением изменений, внесенными разными людьми. Но это отслеживание чисто техническое - т.е. конфликт возникает только в случае изменений одного и того же текста в одной и той же части. CVS не отслеживает логических конфликтов. Т.е. например если кто-то изменил параметры функции foo в файле aaa.c, но в это же время кто-то другой использовал вызов этой функции в файле bbb.c используя старые параметры - CVS не сможет это предупредить.

Основные понятия CVS

У каждого файла имеется свой уникальный номер версии. Номер версии представляет собой несколько целых чисел, разделенных точками, например 1.2.2.5.

Версия самого первого файла обычно 1.1. Каждое успешное изменение увеличивает последнее правое число номера версии на единицу. Но cvs не вводит такого ограничения, как линейность разработки. Т.е у дерева версий могут быть ответвления по которым могут вестись разработки. Любые изменения, сделанные в какой либо ветви могут быть легко внесены в основную линию. У каждой ветви есть свой номер, который добавляется к номеру версии слева. Это позволяет иметь несколько ответвлений от одной версии. Файлы в ветвях нумеруются добавлением еще одной точки и цифры. Т.е для ветви 1.2.2 файлы будут нумерваться как 1.2.2.1, 1.2.2.2, 1.2.2.3 и т.д. Ветви нумеруются четными числами, начиная с 2.

Пример:

                                                     +-------------+
                           Ветвь 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
                                                   / +-------------+
                                                  /
                                                 /
                 +---------+    +---------+    +---------+    +---------+
Ветвь  1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !----! 1.2.2.4 !
               / +---------+    +---------+    +---------+    +---------+
              /
             /
+-----+    +-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !      <- Основная линия
+-----+    +-----+    +-----+    +-----+    +-----+
                !
                !
   Другая       !   +---------+    +---------+    +---------+
 ветвь 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
                    +---------+    +---------+    +---------+

Номера ветвей, оканчивающихся на .0 (например 1.2.0) используются CVS для собственных нужд. Ветвь 1.1.1 имеет специальное значение. Она используется например тогда, когда вы хотите чтобы изменения, внесенные в чужие исходные тексты можно было применить при получении новых версий программы.

Как установить под UNIX?

Перед тем, как устанавливать cvs стоит проверить, а не установлен ли он уже? Наберем в командной строке

$ cvs
bash: cvs: command not found

Так вот, для работы нам надо задать базовый каталог этого самого репозитория. Это можно сделать двумя способами - каждый раз явно указывать его ключем -d (например cvs -d/usr/src/CVS init) или задать переменную среды CVSROOT, что намного удобнее. Можно задать ее глобально, в стартапе шелла, а можно еще как-нибудь. Если с CVS работают несколько человек, есть смысл прописать ее, например (для bash) в /etc/profile:

export CVSROOT=/usr/src/CVS

--- /etc/group ---
devs:x:503:aaz,pavel
------------------

# cvs init
# chgrp devs /usr/src/CVS
# chgrp devs /usr/src/CVS/*
# chgrp devs /usr/src/CVS/CVSROOT/*

Как установить под NT?

Первые шаги в CVS

Импорт исходников и создание модуля

[aaz@aaz xlines]$ cvs import -m "Importing sources" xlines aaz start 
N xlines/Makefile
N xlines/xlines.c

No conflicts created by this import

$ _

Определение модуля

В простых случаях следующих шагов достаточно для определения модуля.

1. Получить рабочую копию файла модулей.

   
   $ cvs checkout CVSROOT/modules
   $ cd CVSROOT
   

2. Отредактировать файл 'modules' и вставить строку, определяющую модуль.

   
   === modules ===
   ## Three different line formats are valid:
   # key     -a    aliases...
   # key [options] directory
   # key [options] directory files...
   #
   # Where "options" are composed of:
   # -i prog         Run "prog" on "cvs commit" from top-level of module.
   # -o prog         Run "prog" on "cvs checkout" of module.
   # -e prog         Run "prog" on "cvs export" of module.
   # -t prog         Run "prog" on "cvs rtag" of module.
   # -u prog         Run "prog" on "cvs update" of module.
   # -d dir          Place module in directory "dir" instead of module name.
   # -l              Top-level directory only -- do not recurse.
   #
   # NOTE:  If you change any of the "Run" options above, you'll have to
   # release and re-checkout any working directories of these modules.
   #
   # And "directory" is a path to a directory relative to $CVSROOT.
   #
   # The "-a" option specifies an alias.  An alias is interpreted as if
   # everything on the right of the "-a" had been typed on the command line.
   #
   # You can encode a module within a module by using the special '&'
   # character to interpose another module into the current module.  This
   # can be useful for creating a module that consists of many directories
   # spread out over the entire source repository.
   xlines xlines
   
   === modules ===

3. Зафиксировать ваши изменения в файле модулей.

   
   $ cvs commit -m "Added the xlines module." modules
   

4. Освободить модуль модулей.

   
   $ cd ..
   $ cvs release -d CVSROOT
   

Подтверждение изменений

$ cvs commit -m "Fixed linking error: added X11 libraries"

$ cvs log Makefile

RCS file: /usr/src/CVS/xlines/Makefile,v
Working file: Makefile
head: 1.2
branch:
locks: strict
access list:
symbolic names:
        start: 1.1.1.1
        aaz: 1.1.1
keyword substitution: kv
total revisions: 3;     selected revisions: 3
description:
----------------------------
revision 1.2
date: 1999/01/30 18:11:13;  author: aaz;  state: Exp;  lines: +1 -1
Fixed linking error: added X11 libraries
----------------------------
revision 1.1
date: 1999/01/30 17:40:11;  author: aaz;  state: Exp;
branches:  1.1.1;
Initial revision
----------------------------
revision 1.1.1.1
date: 1999/01/30 17:40:11;  author: aaz;  state: Exp;  lines: +0 -0
Import sources
=======================================================

Хорошо, теперь предположим, что другой пользователь наконец догадался об этой же самой ошибке и тоже решил опубликовать свой вариант:

$ cvs commit
cvs commit: Examining .
cvs commit: Up-to-date check failed for Makefile
cvs [commit aborted]: correct above errors first!
$ _

Обновление рабочей копии

$ cvs update
RCS file : /usr/src/CVS/xlines/Makefile,v
retrieving version 1.1.1.1 
retrieving version 1.2
Merging differences between 1.1.1.1 and 1.2 into Makefile
rcsmerge: warning: conflicts during merge 
cvs update: conflicts found in Makefile
C Makefile
$ _

=== Makefile ===
xlines: xlines.c
>>>>>>>> Makefile
        gcc xlines.c -o xlines -lX11 -L/usr/lib/X11
========
        gcc xlines.c -o xlines -L/usr/lib/X11 -lX11 
<<<<<<<< 1.2
=== Makefile ===

Итак, мы завершили работу над проектом, собрали его и можем с чистой душой удалить рабочую копию ;) Можно, конечно, просто сделать rm -f xlines/, но лучше воспользоваться командой release:

$ cd ..
$ cvs release -d xlines
M xlines.c
? xlines
You have [1] altered files in this repository.
Are you sure you want to release (and delete) module `xlines`: y
$ _

Работа над проектом с использованием CVS

Начало проекта

Создание модуля

Команды CVS

cvs [cvs_options] command [cmd_options] [arguments]

[cvs_options] - это глобальные опции, которые воздействуют на все подкоманды CVS:

-b bindir	Используйте bindir как директорий, в котором размещена вся программа RCS. Перезаписывает установку переменной среды $RCSBIN и любой прекомпилированный директорий. Этот параметр должен специфицироваться как полное имя пути.
-d cvs_root_directory	Используйте cvs_root_directory как имя пути корневого директория для репозитория. Перезаписывает установку переменной среды $CVSROOT. Этот параметр должен быть специфицирован полным именем пути.
-e editor	Используйте editor для введения журнальной информации о модификации. Перезаписывает установку переменных среды $CVSEDITOR и $EDITOR.
-f	Не читать файл `~/.cvsrc'. Эта опция наиболее часто употребляется из-за неортогональности набора опций CVS. Например, опция `-N' для `cvs log' (выключить отображение имен дескрипторов) не имеет аналога для включения отображения. Так что если вы имеете `-N' как вхождение в `~/.cvsrc' для `diff', то вам может понадобиться `-f' для отображения имен дескрипторов.
-H	Для отображения информации об использовании специфицированной cvs_command (но не для выполнения команды).Если вы не специфицировали имя команды, то `cvs -H' отобразит сводку всех доступных команд.
-l	Не регистрировать cvs_command в истории команды.
-n	Не изменяет каких-либо файлов. Пытается выполнить `cvs_command', но только для выпуска отчетов. Не удаляет, не обновляет и не сливает никаких существующих файлов и не создает новых файлов.
-Q	Делает команду полностью "молчаливой". Команда только генерирует выход для серьезных проблем.
-q	Делает команду в чем-то "молчаливой". Информационные сообщения, такие как отчеты о рекурсиях по поддиректориям, подавляются.
-r	Делает новые рабочие файлы файлами только для чтения. Дает такой же эффект, как если бы переменная среды $CVSREAD была установлена. Умолчание делает рабочие файлы перезаписываемыми.
-t	Трассирует выполнение программы. Отображает сообщения, показывающие шаги функционирования CVS. В частности, полезна с `-n' для изучения потенциального влияния незнакомых команд.
-v	Отображает информацию о версии и авторских правах для CVS.
-w	Делает новые рабочие файлы перезаписываемыми. Перезаписывает установку переменной среды $CVSREAD. По умолчанию файлы создаются перезаписываемыми, если $CVSREAD не установлена или `-r' не задана.

[cmd_options] - это опции, которые зависят от каждой конкретной команды, но большинство команд имеет набор общих опций, которые перечислены ниже. В дальнейшем, при описании команд, эти опции не указываются, а описываются только специальные опции, характерные для данной команды.

• Новейший - файл идентичен своей последней копии в репозитории
• Модифицированный локально - изменения еще не подтверждены
• Нуждающийся в обновлении - кто-то другой изменил файл
• Нуждающийся в слиянии - кто-то другой подтвердил свои изменения а вы - еще нет

cvs status [options] files...

Example:
$ cvs status Makefile
===================================================================
File: Makefile          Status: Locally Modified

   Working revision:    1.4     Wed Feb 10 12:16:33 1999
   Repository revision: 1.4     /usr/src/CVS/xlines/Makefile,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

Опции

Обновление файлов (cvs update)

cvs update [options] files...

Опции

               RCSLOG  RCS     SCCS
               CVS*    cvslog.*
               tags    TAGS
               .make.state     .nse_depinfo
               *~      #*      #*      ,*
               *.old   *.bak   *.BAK   *.orig  *.rej  .del-*
               *.a     *.o     *.so    *.Z     *.elc  *.ln
               core

               $ cvs update -j1.5 -j1.3 foo.c   # обратите внимание на
                                                # порядок...

Выход

Добавление файлов в проект (cvs add)

cvs add [-k kflag][-m 'message'] files...
cvs new [-k kflag][-m 'message'] files...

1. Надо иметь рабочую копию модуля.
2. Создать новый файл внутри вашей рабочей копии модуля.
3. Использовать cvs add <имя файла> для указания CVS, что вы хотите добавить файл.
4. Использовать cvs commit <имя файла>,чтобы оформленно ввести файл в репозиторий. Другие разработчики не могут видеть этот файл, пока вы не завершите этот шаг.

$ cd foo
$ cvs add bar

Опции

Получение исходных текстов из репозитория (cvs checkout)

cvs checkout [options] modules...
cvs co [options] modules...
cvs get [options] modules...

Checkout создает подкаталог, совпадающий с именем модуля и затем распологает в нем файлы и каталоги модуля в соответствии с репозиторием.

Опции

               $ cvs checkout -jTAG:yesterday -jTAG module

Подтверждение изменений (cvs commit)

cvs commit [-lnRf] [-m `log_message'|-F logfile] [-r revision] [files...]
cvs ci [-lnRf] [-m `log_message'|-F logfile] [-r revision] [files...]

Выявление различий между модификациями (cvs diff)

cvs diff [-l] [rcsdiff_options] [[-r rev1 | D date1] [-r rev2 | -D date2]] [files...]

Если даны какие-то имена файлов, то только эти файлы будут сравниваться. Если даны какие-то директории, то будут сравниваться все файлы в них.

Статус выхода будет 0, если различие не найдено, 1, если различие найдено, и 2 при ошибке.

Созданием файла `$CVSROOT/CVS/ROOT/history' должно быть задействовано ведение журнала.

ПРЕДУПРЕЖДЕНИЕ: history использует `-f', `-l', `-n', и `-p' способами, которые конфликтуют с нормальным использованием в CVS.

Опции

Импорт исходных текстов с использованием vendor branches

cvs import [-options] repository vendortag releasetag...

Аргумент repository дает имя директория (или путь к директорию) в корневом директории CVS для репозиториев; если директорий не существует, то import создает его.

Когда вы используете импорт для обновления исходного текста, который был ранее модифицирован, в вашем репозитории, вас поставят в известность о любых файлах, которые конфликтуют в двух ветвях разработки; используйте `checkout -j' для улаживания конфликтов, как import рекомендует делать. По умолчанию некоторые имена файлов игнорируются во время исполнения import: имена, ассоциированные с администрацией CVS или с другими системами управления общими исходными текстами; общие имена для файлов заплат, объектных файлов, архивных файлов и файлов резервных копий редактора; и другие имена, которые обычно искусственно создаются некоторыми утилитами. Ныне список игнорируемых по умолчанию файлов включает файлы, соответствующие таким именам:

     RCSLOG   RCS     SCCS
     CVS*     cvslog.*
     tags     TAGS
     .make.state      .nse_depinfo
     *~       #*      #*      ,*
     *.old    *.bak   *.BAK   *.orig  *.rej  .del-*
     *.a      *.o     *.so    *.Z     *.elc  *.ln
     core

Если существует файл `$CVSROOT/CVSROOT/cvswrappers', то любые файлы, чьи имена соответствуют спецификациям в этом файле, будут рассматриваться как пакеты, и будет производиться подходящая фильтрация на файле директории перед его импортом.

Внешний исходный текст сохраняется в ветви RCS первого уровня, по умолчанию - 1.1.1. Обновления - это листья этой ветви; например, файлы от первого импортированного набора исходных текстов будут модификацией 1.1.1.1, файлы от первого импортированного обновления будут модификацией 1.1.1.2 и т.д.

Требуется по крайней мере три аргумента. repository нужен для идентификации набора исходных текстов. vendortag - это дескриптор для всей ветви (например, для 1.1.1). Надо также специфицировать минимум один releasetag для идентификации файлов на листьях, создаваемых при каждом исполнении import.

Опции

Удаление файлов из проекта (cvs remove)

cvs remove [-lR] files...
cvs rm [-lR] files...
cvs delete [-lR] files...

Модули изменяются. Новые файлы добавляются, старые исчезают. И все же вы хотите иметь возможность искать точную копию старых выпусков модуля.

Вот что вы можете сделать для удаления файла из модуля при сохранении возможности поиска старых модификаций:

1. Убедитесь, что у вас нет незафиксированных модификаций файла. Вы можете также использовать команды status или update. Если вы удаляете файл без фиксации ваших изменений, то вы, конечно, не сможете отыскать его, как могли бы перед его удалением.
2. Удалите файл из вашей рабочей копии модуля. Можно использовать, например, команду rm.
3. Используйте cvs remove <имя файла> для указания CVS, что вы действительно хотите удалить его.
4. Используйте cvs commit <имя файла> для действительного удаления файла из репозитория.

  $ ls
  CVS   ja.h  oj.c
  $ rm oj.c
  $ cvs remove oj.c
  cvs remove: scheduling oj.c for removal
  cvs remove: use `cvs commit' to remove this file permanently
  $ cvs add oj.c
  U oj.c
  cvs add: oj.c, version 1.1.1.1, resurrected

  $ rm oj.c
  $ cvs update oj.c
  cvs update: warning oj.c was lost
  U oj.c

Опции

Пересылка и переименование файлов

Нормальный путь переименования

  $ mv <стар> <нов>
  $ cvs remove <стар>
  $ cvs add <нов>
  $ cvs commit -m "Renamed <стар> to <нов>" <стар> <нов>

Это простейший способ переслать файл, он не подвержен ошибкам и сохраняет историю того, как он сделан. Заметим, что для доступа к истории файла вы должны специфицировать старое или новое имя в зависимости от того, к какой части истории вы имеете доступ. Например, cvs log <стар> даст часть журнала вплоть до времени переименования.

Когда <нов> зафиксирован, его номера модификаций снова начнутся с 1.0, так что если это вам нежелательно, то используйте опцию `-r rev' для фиксации.

Пересылка файла истории

  $ cd $CVSROOT/ <модуль>
  $ mv <стар>,v <нов>,v

• журнал изменений и номера модификаций не затрагиваются.

• Нелегко будет вызвать старые выпуски модуля из репозитория. (Файл будет выглядеть как новый даже в модификациях от времени, перед которым он переименовывался).
• Нет журнальной информации о том, когда файл переименовывался.
• Могут случиться неприятности, если кто-то получит доступ к файлу во время вашей пересылки. Убедитесь, что никто не выполняет команды CVS во время этой пересылки.