The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Программирование, языки" (Архив | Для печати)

Русская документация по CVS


Оригинал:
ruxy.org.ru Почти весь изложенный ниже материал написан исходя из того, что мы работаем под одной из версий Linux, но я не сомневаюсь, что для других *nix'ов изменения будут крайне незначительные
  ///

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

CVS (Concurrent Versions System) - это система контроля версий файлов. Основное предназначение - сохранение истории изменения файлов. (В качестве примеров в дальнейшем будут использоваться исходные тексты на языке С.)

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

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

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

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

CVS не помогает строить окончательные проекты - она не взаимодействует с makefile'ами и прочими средствами. Это фактически просто репозиторий файлов с древовидной структурой. Т.е. она не будет следить за обновлением файлов необходимых для построения проекта.

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

Основные понятия 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 имеет специальное значение. Она используется например тогда, когда вы хотите чтобы изменения, внесенные в чужие исходные тексты можно было применить при получении новых версий программы.

Оглавление

Где взять?

Ну, версия под юникс берется обычно на любом ближайшем ftp, на котором есть софт под юникс и линукс, в частности. Например, здесь. Для различных дистрибутивов Linux есть варианты в .rpm, .deb или просто .tar.gz.

С версией под Win32 немного сложнее - все что я нашел, это вот это.


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

[!] Для начала стоит залогинится под рутом или просто сделать su, поскольку установка потребует некоторых привилегий.

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


$ cvs
bash: cvs: command not found
Облом-с, его-таки нету. Но если же вы получили список ключей - значит скорее всего cvs уже установлен. Тогда все что идет
до сюда, можно пропустить. Итак, у вас уже есть файл с названием, похожим на cvs-1.x.x.rpm или cvs-1.x.x.tar.gz. Ну, первый вариант потребует от вас наименьших усилий для установки - для этого надо всего лишь набрать в коммандной строке:

# rpm -i cvs-1.9-.rpm
failed dependencies:
        rcs is needed by cvs-1.9-5
Так. Стоило все-таки сначала почитать какие-нибудь доки что-ли. Ладно читаем описание пакета - "cvs is frontend for rcs". Ладно, ставим rcs, благо он есть тут же:

# rpm -i rcs-5.7-7.i386.rpm
Вроде установился. Теперь повторяем установку cvs. Ура, установилось! Если же нет, то надо посмотреть, чего не хватает и просто установить нужный пакет.

[...]

Ну вот, теперь cvs радостно сообщает нам о своем присутствии и можно двигаться дальше. Для начала стоит прочитать README, да и все остальное, что теперь лежит в каталоге /usr/doc/cvs-1.x.

Теперь попробуем что-нибудь сделать, например:


# cvs init
cvs init: No CVSROOT specified!  Please use '-d' option
cvs [init aborted]: or set CVSROOT environment variable.
Ага. Как уже говорилось вначале, cvs хранит все свои данные в репозитории, и, конечно, наш свежепоставленный CVS не знает, где же находится текущий репозиторий (их, в принципе, может быть и несколько, но об это - позже, далее пока будет рассматриваться случай единого репозитория).

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


export CVSROOT=/usr/src/CVS
Естесственно, можно расположить репозиторий в любом каталоге, а не только в /usr/src/CVS. Здесь надо сказать пару слов о правах доступа. Поскольку с CVS будут скорее всего работать несколько человек, то он должен быть доступен для них всех и на чтение, и на запись. Для это стоит создать отдельную группу, например devs, и установить права на /usr/src/CVS как drwxrwx---. Тех, кто будет работать с CVS надо, соответственно, просто добавлять в эту группу.

--- /etc/group ---
devs:x:503:aaz,pavel
------------------
Теперь надо создать и инициализировать репозиторий. Это делается коммандой init, но тут есть маленький подвох. Если это сделать от рута, то только он и сможет пользоваться cvs. Если же пытаться создавать репозиторий от юзера, то необходимо право создавать каталоги в каталоге, базовом для репозитория. Поэтому лучше сделать init от рута, а потом сменить группу на devs

# cvs init
# chgrp devs /usr/src/CVS
# chgrp devs /usr/src/CVS/*
# chgrp devs /usr/src/CVS/CVSROOT/*
Вот и все. Теперь о местонахождении репозитория можно забыть. Работать с ним напрямую не рекомендуется, для выполнения практически любых операций есть соответствующие команды cvs.
Оглавление

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


Not implemented yet!
Оглавление

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

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

Итак, cvs установлен. Что теперь? Неплохо бы начать какой-нибудь проект. Для примера возьмем программу на языке C, которая пока состоит у нас из одного модуля и Makefile'а. Пусть они находятся у нас в каталоге xlines (так называется мой реальный проект игрушки ;) Дадим знать о них 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

$ _
Если не указать ключ -m, то для ввода комментария будет запущен редактор, определенный по умолчанию. "xlines" - это каталог репозитория (а он тоже имеет древовидную структуру), в котором будут храниться файлы проекта. Два следующие параметра - это vendor_tag и release_tags они используются для имопорта уже готовых исходников и будут рассмотрены
далее. Теперь исходные файлы можно с чистой совестью удалить ;)

Получение копии фалов из репозитория

Можно начинать совместную работу с проектом - все пользователи могут получить свои копии файлов проекта дав команду

$ cvs checkout
U xlines/Makefile
U xlines/xlines.c
$ _
В текущем каталоге появился новый подкаталог xlines, в котором есть уже знакомые нам файлы Makefile и xlines.c и еще один подкаталог CVS, в котором хранятся данные о проекте, которые используются при подтверждении и отслеживании изменений. Теперь дадим команду

$ cvs log

RCS file: /usr/src/CVS/xlines/Makefile,v
Working file: xlines/Makefile
head: 1.1
branch: 1.1.1
locks: strict
access list:
symbolic names:
        start: 1.1.1.1
        aaz: 1.1.1
keyword substitution: kv
total revisions: 2;     selected revisions: 2
description:
----------------------------
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
=============================================================================

RCS file: /usr/src/CVS/xlines/xlines.c,v
Working file: xlines/xlines.c
head: 1.1
branch: 1.1.1
locks: strict
access list:
symbolic names:
        start: 1.1.1.1
        aaz: 1.1.1
keyword substitution: kv
total revisions: 2;     selected revisions: 2
description:
----------------------------
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
=============================================================================
Ага. Эта версия получила номер 1.1 и комментарий "Initial revision".

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

Следуюший шаг - определить модуль в файле `modules'. Некоторые команды работают без этого шага, но другие (в первую очередь release) требуют, чтобы все модули были должным образом определены в файле `modules'.

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

  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
    
Теперь каждый пользователь может работать со своей копией файлов. Попробовав собрать проект получаем ошибку - я забыл указать в makefil'е библиотеку X11. Редактируем его, добавляя нужную строчку и проверяем.

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

Работает, а поэтому неплохо было бы, чтобы об этом изменении узнали все пользователи. Так что даем комманду commit

$ 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
=============================================================================
Как видно из лога изменений, новая версия makefil'а получила версию 1.2, одна строка была добавлена, одна удалена, что означает, что мы ее просто отредактировали.

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


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

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

Это означает, что у нас не самая свежая копия Makefile и ее следует обновить перед тем, как вносить что-то свое. Делаем это:

$ 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 ===
Маркером >>>>>>>> cvs отметил начало конфликтного участка в пользовательской копии файла, а после маркера ======== идет тот вариант текста, который есть в репозитории. Маркером <<<<<<<< отмечен конец конфликтоного участка. Теперь надо отредактировать свою копию в соответствии с той, что хранится в репозитории, удалить маркеры и подтвердить изменения.

Итак, мы завершили работу над проектом, собрали его и можем с чистой душой удалить рабочую копию ;) Можно, конечно, просто сделать 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 проверит, есть ли неподтвержденные изменения и (если указан ключ -d) удалит рабочую копию файлов. Строка '? xlines' означает, что обнаружен неизвестный файл xlines - это наш скомпилированный бинарник.
Оглавление

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

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

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

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

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

Затем необходимо определить созданный модуль, как описано здесь

Команды CVS

Любое взаимодействие с cvs осуществляется с помощью команд, имеющих примерно одинаковый синтаксис:

cvs [cvs_options] command [cmd_options] [arguments]
Где [command] - это команда, а [options] - опции. Многие команды имеют синонимы - т.е. вы можете использовать либо cvs remove, либо cvs rm, либо cvs delete - все синонимы перечислены в описании команды.

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

ПРЕДУПРЕЖДЕНИЕ: команда `history' - исключение; она поддерживает много опций, которые конфликтуют даже с этими стандартными опциями.
-D date_spec Для использования самых последних модификаций не позднее, чем date_spec . date_spec - единственный аргумент, некоторая дата в прошлом. Спецификация является распределенной, когда вы используете ее для создания личной копии файла исходного текста; т.е. когда вы получаете рабочий файл, используя `-D', CVS записывает вами специфицированную дату, так что дальнейшие обновления в том же директории будут использовать ту же дату (если вы не перезапишете ее явно). Множество форматов дат поддерживается встроенными средствами RCS, подобными описанным в co(1), но не точно такими же. date_spec интерпретируется как находящаяся в местном часовом поясе, если не специфицировано другое. Примеры значимых спецификаций дат включают: 1 month ago 2 hours ago 400000 seconds ago last year last Monday yesterday a fortnight ago 3/31/92 10:00:07 PST January 23, 1987 10:05pm 22:00 GMT `-D' доступна с командами checkout.diff.export.history.rdiff.rtag и update. (Команда history использует эту опцию несколько отличным способом;). Не забывайте заключать в кавычки аргумент флага `-D', чтобы ваш командный файл не интерпретировал пробелы как разделители аргументов. Команда с использованием флага `-D' может выглядеть примерно так: $ cvs diff -D "1 hour ago" cvs.texinfo
-f Когда вы специфицируете дату или дескриптор для команды CVS, то они в норме игнорируют файлы, которые не содержат этот дескриптор (или не существовали до этой даты). Используйте опцию `-f', если вы хотите искать файлы, даже когда нет соответствий для дескриптора или даты. (Будет использована самая последняя модификация файла). `-f' доступна с такими командами: checkout, export, rdiff, rtag и update. ПРЕДУПРЕЖДЕНИЕ: Команда commit также имеет опцию `-f', но она имеет другое поведение для этой команды.
-H Помощь (help). Описывает опции, доступные для этой команды. Это единственная опция, поддерживаемая для всех команд CVS.
-k kflag Изменяет обработку ключевых слов в RCS по умолчанию. Ваша спецификация kflag является распределенной, когда вы используете ее для создания личной копии файла исходных текстов; т.е. когда вы используете эту опцию с командами checkout или update, CVS ассоциирует ваш выбранный kflag с файлом и продолжает использовать его с будущими командами обновления в том же файле, пока вы не специфицируете другое. Опция `-k' доступна с командами add, checkout, diff и update.
-l Локальность; для прогона только в текущем рабочем директории, без рекурсии по поддиректориям. ПРЕДУПРЕЖДЕНИЕ: Это не то же самое, что общая опция `cvs -l', которую вы специфицируете слева от команды CVS! Доступна со следующими командами: checkout, commit, diff, export, log, remove, rdiff, rtag, status и update.
-m message Для использования message в качестве журнальной информации, вместо вызова редактора. Доступна со следующими командами: add, commit и import.
-n Не прогонять любую программу checkout/commit/tag. (Программа может быть специфицирована для прогона каждой из этих функциональных единиц в модульной базе данных; но эта опция обойдет их). ПРЕДУПРЕЖДЕНИЕ: Это не то же самое, что общая опция `cvs -n', которую вы можете специфицировать слева от команды CVS! Доступна с командами checkout, commit, export и rtag.
-P Для отсечения (удаления) директориев, ставших пустыми после обновления командами checkout или update.В норме пустой директорий (без файлов с управляемыми модификациями) остается "одиноким".Спецификация `-P' "тихо" удаляет эти директории из ваших оформленно выведенных исходных текстов. Она не удаляет директорий из репозитория, а только из вашей оформленно выведенной копии. Заметим, что эта опция подразумевается при использовании опций `-r' или `-D' команд checkout и export.
-p Направляет файл, извлекаемый при поиске из репозитория, на стандартный выход, а не на запись в текущем директории. Доступна с командами checkout и update.
-w Специфицирует имена файлов, которые должны быть отфильтрованы. Эту опцию можно использовать повторно. Спецификацией может быть образец имени файла того же типа, который вы можете специфицировать в файле `.cvswrappers'. Доступна с командами import и update.
-r tag Для использования модификации, специфицированной аргументом tag , вместо головной (по умолчанию) модификации. Так же как любые дескрипторы, определенные командами tag и rtag, два специальных дескриптора всегда доступны: `HEAD' ссылается на самую последнюю версию, доступную в репозитории, а `BASE' ссылается на модификацию, которую вы оформленно вывели последней в текущий рабочий директорий. Спецификация дескриптора является распределенной, когда вы используете эту опцию при checkout или update для создания вашей собственной копии файла: CVS помнит дескриптор и продолжает использовать его в будущих командах обновления, пока вы не специфицируете другое. Дескриптор может быть символьным или численным. Специфицирование глобальной опции `-q' с командной опцией `-r' часто полезно для подавления предупреждений, когда файл истории RCS не содержит специфицированного вами дескриптора. ПРЕДУПРЕЖДЕНИЕ: Это не то же самое, что общая опция `cvs -r', которую вы специфицируете слева от команды CVS! `-r' доступна с командами checkout, commit, diff, history, export, rdiff, rtag и update.
Оглавление

Состояние файла

Каждый файл может находится в одном из четырех состояний: Для получения текущего состояния файла можно применить команду cvs status:

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)

Опции

-vДля расширенной информации. В добавление к нормально отображаемой информации печатать все символические дескрипторы вместе с численными значениями модификаций или ветвей, на которые они ссылаются.
Оглавление

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

Команда update производит обновление рабочей копии файлов в соответствии с репозиторием.

cvs update [options] files...
После вашего исполнения checkout'а для создания вашей личной копии исходных текстов из общего репозитория другие разработчики будут продолжать изменять централизованные исходные тексты. Время от времени, когда будет удобно, в процессе вашей разработки вы можете использовать команду update изнутри вашего рабочего директория для согласования вашей работы с любыми модификациями, сделанными в репозитории после вашего последнего checkout или update.

Опции

-A Переустановить любые распределенные дескрипторы, даты или опции `-k'. (Если вы получили рабочую копию файла применением одной из опций `-r',`-D' или `-k', то CVS запомнит соответствующий дескриптор, дату или kflag и продолжит использовать их в будущих обновлениях; используйте опцию `-A', чтобы заставить CVS забыть эти спецификации и искать головную модификацию файла).
-d Создать любые директории, существующие в репозитории, если их нет в рабочем директории. В норме update действует только на директориях и файлах, которые уже внесены в ваш рабочий директорий. Это полезно для обновления директориев, созданных в репозитории после начального checkout; но, к сожалению, это дает побочный эффект. Если вы преднамеренно избегаете некоторых директориев в репозитории при создании вашего рабочего директория (или используя имя модуля или явным перечислением нужных вам файлов и директориев в командной строке), то обновление с `-d' создаст не те директории, какие вы хотите.
-I name Игнорировать файлы, чьи имена соответствуют name (в вашем рабочем директории) при update. Вы можете специфицировать `-I' более одного раза в командной строке для игнорирования нескольких файлов. По умолчанию update игнорирует файлы, чьи имена соответствуют следующим:

               RCSLOG  RCS     SCCS
               CVS*    cvslog.*
               tags    TAGS
               .make.state     .nse_depinfo
               *~      #*      #*      ,*
               *.old   *.bak   *.BAK   *.orig  *.rej  .del-*
               *.a     *.o     *.so    *.Z     *.elc  *.ln
               core
Используйте `-I!' для исключения игнорирования любых файлов. См. Раздел B.8 о других способах заставить CVS игнорировать некоторые файлы.
-Wspec Специфицировать имена файлов, которые нужно фильтровать при update. Можно использовать эту опцию повторно. spec может быть шаблоном имени файла того же типа, что вы специфицируете в файле `.cvswrappers'.
-j branch Слить изменения, сделанные между результирующей модификацией и модификацией, на которой она базируется (например, если ссылаются на branch, то CVS сольет все изменения, сделанные в этой ветви, в ваш рабочий файл). При двух опциях `-j' CVS сольет изменения между двумя соответствующими модификациями.Эту опцию можно использовать для удаления какого-то кусочка из вашего рабочего файла; если файл `foo.c' базируется на модификации 1.6 и вы хотите удалить изменения, сделанные между 1,3 и 1.5, то можно выполнить:

               $ cvs update -j1.5 -j1.3 foo.c   # обратите внимание на
                                                # порядок...
Вдобавок, каждая опция -j может содержать опциональную спецификацию даты, которая при использовании с ветвями может ограничить выбранную модификацию до одной со специфицированной датой. Опциональная дата специфицируется добавлением двоеточия (:) к дескриптору: `-jSymbolic_Tag:Date_Specifier'.

Выход

U fileФайл обновлен по отношению к репозиторию. Это делается для любого файла, существующего в репозитории, но не в ваших исходных текстах, и для файлов, которые вы не изменяли, но которые не являются самыми поздними версиями, доступными в репозитории.
A fileФайл был добавлен к вашей личной копии исходных текстов и будет добавлен к репозиторию при исполнении commit на этом файле. Это напоминание для вас, что файл нужно фиксировать.
R file Файл удален из вашей личной копии исходных текстов и будет удален из репозитория при выполнении commit на этом файле. Это напоминание для вас, что файл нужно фиксировать.
M file Файл модифицируется в вашем рабочем директории. `M' может указывать на одно из двух состояний файла, на котором вы работаете: или нет модификаций того же файла в репозитории, так что ваш файл остается таким, каким вы видели его в последний раз; или есть модификация в репозитории и в вашей копии, но они слиты успешно без конфликта в вашем рабочем директории. CVS печатает некоторые сообщения, если она сливает вашу работу, и делается резервная копия вашего рабочего файла (как он выглядел перед исполнением update). Точное имя этого файла печатается при исполнении update.
C file Обнаружен конфликт при попытке слияния ваших изменений в file с изменениями из репозитория. file (копия в вашем рабочем директории) - это теперь выход команды rcsmerge(1) на двух модификациях; немодифицированная копия вашего файла есть также в вашем рабочем директории, с именем `.#file.revision', где revision - это модификация RCS, от которой произошел ваш модифицированный файл. (Заметим, что некоторые системы автоматически чистят файлы, начинающиеся с `.#', если ими не пользовались несколько дней. Если вы хотите сохранить копию вашего первоначального файла, то хорошо бы переименовать его.)
? file file находится в вашем рабочем директории, но не соответствует ничему в репозитории и не находится в списке файлов CVS для игнорирования (см. описание опции `-I'). Заметим, что не выдается предупреждений для некондиционных директориев, встречаемых CVS. Директорий и все его содержимое незаметно игнорируется.
Оглавление

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


cvs add [-k kflag][-m 'message'] files...
cvs new [-k kflag][-m 'message'] files...
Команда add используется для добавления новых файлов в текущий модуль. Для добавления нового файла к модулю выполняются следующие шаги:
  1. Надо иметь рабочую копию модуля.
  2. Создать новый файл внутри вашей рабочей копии модуля.
  3. Использовать cvs add <имя файла> для указания CVS, что вы хотите добавить файл.
  4. Использовать cvs commit <имя файла>,чтобы оформленно ввести файл в репозиторий. Другие разработчики не могут видеть этот файл, пока вы не завершите этот шаг.
Вы можете также использовать команду add для добавления нового директория в модуль. Не в пример большинству других команд, add нерекурсивна. Вы даже не можете ввести cvs add foo/bar! Взамен надо:

$ cd foo
$ cvs add bar
Добавленные файлы не помещаются в репозиторий исходных текстов, пока вы не используете commit для фиксации изменений. Выполнение add для файла, который был удален командой remove, восстановит файл, пока не вмешается commit.

Опции

-k kflag Эта опция специфицирует способ по умолчанию, которым этот файл будет оформленно выводиться. См. rcs(1) и co(1). Аргумент kflag сохраняется в файле RCS и может быть изменен командой admin -k. Специфицирование `-ko' полезно для оформленного ввода исполняемых файлов, которые не должны иметь расширенных строк идентификаторов RCS.
-m description С помощью этой опции вы можете дать описание для файла. Описание появляется в журнале истории (если он задействован). Оно также будет сохранено в файле истории RCS в репозитории при фиксации файла. Команда log отображает это описание. Описание может быть изменено при помощи `admin -t'. Если вы опускаете флаг `-m description ', то используется пустая строка. Тогда описание не запрашивается.
Оглавление

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


cvs checkout [options] modules...
cvs co [options] modules...
cvs get [options] modules...
Создает каталог, содержащий копии файлов из модулей modules. Это действие необходимо выполнить перед началом работы над локальной копией файлов.

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

Опции

-A Переустановить любые распределенные дескрипторы, даты и опции `-k'. (Если ваш рабочий файл использует одну из опций `-r', `D' или `-k',то CVS запомнит соответствующие дескриптор, дату или kflag и продолжит использовать их в будущих обновлениях; используйте опцию `-A', чтобы заставить CVS забыть эти спецификации и искать головную модификацию файла).
-c Скопировать файл модуля, отсортированный, на стандартный выход вместо создания или модификации любых файлов или директориев в вашем рабочем директории.
-d dir Создать директорий с именем dir для рабочих файлов вместо использования имени модуля. Без использования `-N' пути, создаваемые при dir, будут максимально короткими.
-j tag Слить изменения, сделанные между результирующей модификацией и модификацией, на которой она базируется (например, если tag ссылается на ветвь, CVS сливает все изменения, сделанные на этой ветви, в ваш рабочий файл). С двумя опциями `-j tag' CVS сольет изменения между двумя соответствующими модификациями. Это можно использовать для отмены изменений, сделанных между двумя модификациями в вашу рабочую копию или для пересылки изменений между различными ветвями. Вдобавок каждая опция `-j' может содержать опциональную спецификацию даты, которая при использовании с ветвями может ограничить выбор модификации специфицированной датой. Опциональная дата специфицируется добавлением `:' к tag. В этом примере вы сливаете только что импортированные файлы, которые могут конфликтовать с локальными изменениями:

               $ cvs checkout -jTAG:yesterday -jTAG module
-N Полезна только вместе с `d dir'. С этой опцией CVS не укорачивает пути модуля в вашем рабочем директории. (В норме CVS максимально укорачивает пути, когда вы явно специфицируете целевой директорий).
-s Подобна `-c', но включает статус всех модулей и сортирует их по строке статуса.
Оглавление

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


cvs commit [-lnRf] [-m `log_message'|-F logfile] [-r revision] [files...]
cvs ci [-lnRf] [-m `log_message'|-F logfile] [-r revision] [files...]
Команда commit используется тогда, когда вы хотите внести в репозиторий сделанные в рабочей копии изменения и сделать их доступными для остальных разработчиков. Если вы не указываете конкретный файл для фиксации, то просматриваются все файлы в текущем каталоге и фиксируются, если они были изменены. (По умолчанию процесс присходит рекурсивно, т.е. также просматриваются и все подкаталоги. Если надо ограничить область просмотра, используется опция -l).

Если какой-либо файл имеет более старую версию, чем в репозитории, но был изменен, то фиксация не выполняется, а выводится сообщение Up-to-date check failed. Это означает, что сначала необходимо обновить рабочую копию при помощи команды update.

Если все правильно, и не указан ключ -m, то CVS вызывает редактор для ввода записи в журнале, которая впоследствии может быть извлечена командой log.

Опции

Опция -r предназначена для указания, с каким номером версии будут зафиксированы файлы. Т.е. если выполнить
$ cvs commit -r 3.0
то все (даже неизмененные файлы получат номер версии 3.0. При этом версия не может быть меньше текущей, т.е. если существует можификация файлов 2.0, то нельзя сделать cvs commit -r 1.5.
Оглавление

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


cvs diff [-l] [rcsdiff_options] [[-r rev1 | D date1] [-r rev2 | -D date2]] [files...]
Команда diff используется для сравнения различных модификаций файлов. Действие по умолчанию - сравнить ваши рабочие файлы с модификациями, на которых они основаны, и сообщить о любых найденных различиях.

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

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

Оглавление

Просмотр статуса файлов и пользователей

cvs history [-report] [-flags] [-options args] [files...]
CVS может вести файл истории, который отслеживает каждое употребление команд checkout, commit, rtag, update и release. Вы можете использовать history для отображения этой информации в различных форматах.

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

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

Опции

Некоторые опции, показанные выше как `-report', контролируют, какой вид отчета генерируется:
-c Сообщение на каждый случай использования commit (т.е. на каждый случай модификации репозитория).
-e Все типы записей; эквивалентно спецификации `-xMACFROGWUT'.
-m module Сообщение о конкретном модуле module. (Вы можете употребить `-m' более одного раза в командной строке).
-o Отчет об оформленно выведенных модулях.
-T Отчет о всех дескрипторах.
-x type Извлечь конкретный набор типов записей type из истории CVS. Типы указываются одной буквой, и эти буквы вы можете специфицировать в комбинации. Некоторые команды имеют единственный тип записей:
F release
O checkout
T rtag
Один из четырех типов записей может получаться от обновления:
C Слияние было необходимо, но обнаружены конфликты (требуется ручное слияние).
G Слияние было необходимо и прошло успешно.
U Рабочий файл был скопирован из репозитория.
W Рабочая копия файла была удалена во время обновления (так как он вышел из репозитория).
Один из трех типов записей происходит от фиксации:
A Файл был добавлен в первый раз.
M Файл был модифицирован.
R Файл был удален.


Опции `-flags' ограничивают или расширяют отчет, не требуя аргументов опции:
-a Показать данные для всех пользователей (умолчание - показать данные только для пользователя, выполняющего history).
-l Показать только последнюю модификацию.
-w Показать только записи для модификаций, сделанных из того же рабочего директория, где выполняется history. Опции `-options args' ограничивают отчет, основанный на аргументе:
-b str Показать данные, начиная с записи, содержащей строку str в имени модуля, имени файла или в пути в репозитории.
-D date Показать данные, начиная с date. Это несколько отлично от нормального употребления `-D date', которое выбирает новейшую модификацию, старше, чем date.
-p repository Показать данные для конкретного репозитория исходных текстов repository (можно специфицировать несколько опций `-p' на одной командной строке).
-r rev Показать записи, ссылающиеся на модификации, начиная с того момента, когда модификация или дескриптор с именем rev появляется в индивидуальных файлах RCS. В каждом файле RCS ищется эта модификация или дескриптор.
-t tag Показать записи с того момента,когда дескриптор tag был в последний раз добавлен к файлу истории. Это отличается от вышеуказанного флага `-r' тем, что данная опция читает только файл истории, а не все файлы RCS, и работает намного быстрее.
-u name Показать записи для пользователя name.
Оглавление

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


cvs import [-options] repository vendortag releasetag...
Используйте import для включения всех внешних исходных текстов (например, исходных текстов поставщика) ваш репозиторный директорий. Вы можете использовать эту команду как для первоначального создания репозитория, так и для разового обновления модуля из внешнего источника.

Аргумент 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/cvsignore, то любые файлы, чьи имена соответствуют спецификациям в этом файле, будут также игнорироваться.

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

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

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

Опции

-b branch Специфицировать ветвь первого уровня другую, чем 1.1.1. Если не дан флаг `-b branch', то модификации всегда делаются на ветви 1.1.1 - даже если дан vendortag, соответствующий другой ветви! В этом случае дескриптор может быть переустановлен на 1.1.1.
-k subst Указать желательный режим расширения ключевых слов RCS. Эта установка будет применяться ко всем файлам, созданным во время импорта, но не к файлам ранее существовавшем в репозитории. См. co(1) для полного списка значимых установок `-k'. Если вы оформленно вводите исходные тексты, которые содержат ключевые слова RCS и вы хотите оставить их нетронутыми, то используйте флаг `-ko' при импорте файлов. Эта установка указывает, что RCS не будет применять расширения кодовых слов при оформленном выводе. Это также полезно для оформленного ввода исполняемых файлов.
-I name Специфицировать имена файлов, которые надо игнорировать при импорте. Эту опцию можно использовать повторно. Чтобы избежать игнорирования любых файлов вообще (даже тех, которые игнорируются по умолчанию), специфицируйте `-I!'. name может быть шаблоном имени файла того же типа, который вы специфицируете в файле `.cvsignore'.
-W spec Специфицировать имена файлов, которые надо фильтровать при импорте. Эту опцию можно использовать повторно. spec может быть шаблоном имени файла того же типа, который вы можете специфицировать в файле `.cvswrapperers'.
Оглавление

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


cvs remove [-lR] files...
cvs rm [-lR] files...
cvs delete [-lR] files...
Используйте эту команду для декларирования того, что вы хотите удалить файлы из репозитория исходных текстов. Как большинство команд CVS, `cvs remove' работает на файлах в вашем рабочем директории, а не прямо на репозиторий. Для безопасности она также требует, чтобы вы сначала стерли специфицированные файлы в вашем рабочем директории.

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

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

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

  $ 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
Если вы еще не выполнили remove, но уже стерли файл можно сделать update:

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

Опции

-lЛокальность; выполнять только в текущем рабочем директории.
-RФиксировать директории рекурсивно. Это - по умолчанию.
Оглавление

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

Пересылка файлов в другой директорий или переименование их нетрудны, но некоторые пути для этого не совсем очевидны. В нижеприводимых примерах предполагается, что файл <стар> переименовывается в <нов>.

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

Нормальный путь пересылки файла - это копирование <стар> в <нов> и затем применение нормальных команд CVS для удаления <стар> из репозитория и добавления <нов> в него. (Они оба могут содержать относительные пути, например,foo/bar.c).

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

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

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

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

Этот метод более опасен, ибо он включает пересылку файлов внутри репозитория.

  $ cd $CVSROOT/ <модуль>
  $ mv <стар>,v <нов>,v
Преимущества: Недостатки: (c) l999 AAZ


Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру