Что такое cvs в тестировании
Материал из CustisWiki
CVS (Concurrent Versions System) является системой контроля версий: она хранит историю изменений определенного набора файлов, как правило программного обеспечения, и позволяет нескольким (порой весьма удаленным друг от друга) разработчикам совместно работать над одним проектом. CVS популярна в мире открытого ПО. Система разрабатывается по лицензии GNU General Public License.
Краткую флеш-презентацию введение в CVS (какие проблемы он решает, каковы основные понятия, достоинства и недостатки, и т.п.) можно просмотреть здесь.
CVS использует архитектуру клиент-сервер: сервер хранит текущую версию (версии) проекта и историю изменений, а клиент соединяется с ним, чтобы получить рабочую копию (данная процедура называется check-out), затем проделать необходимые изменения и позже залить эти изменения (check-in). Обычно клиент и сервер соединяются через локальную сеть или через Интернет, но могут работать и на одной машине, если необходимо вести историю версий локального проекта. CVS есть во всех популярных операционных системах.
Несколько клиентов могут работать над копиями проекта одновременно. Когда они отправляют результаты, сервер пытается слить их изменения в репозитории вместе. Если это не удается, например, в случае, когда два клиента изменили одни и те же строки в определенном файле, сервер не примет изменения от последней check-in операции и сообщит клиенту о конфликте, который должен быть исправлен вручную. Если check-in операция завершилась успешно, то номера версий всех затронутых файлов автоматически увеличиваются, и сервер записывает комментарий, дату и имя пользователя в свой журнал.
Клиенты также могут сравнить различные версии файлов, запросить полную историю изменений или получить исторический образ проекта на определенное число или по номеру ревизии.
CVS также может содержать различные ветки проекта. Например, стабильная версия проекта может составлять одну ветвь (branch), в которую вносятся только исправления ошибок, тогда как активная разработка может вестись в параллельной ветке, которая включает значительные улучшения или изменения с момента выхода стабильной версии.
CVS использует механизм delta compression для эффективного хранения различных версий одного и того же файла.
Содержание
Терминология
Проекты в CVS хранятся в виде модулей. Модуль — это набор файлов проекта. Сервер CVS может обслуживать несколько модулей; все модули хранятся в репозитории. Локальная копия модуля, полученная с помощью CVS клиента, называется рабочей копией.
История и статус
CVS является развитием более ранней системы контроля версий, имеющей название Revision Control System (RCS), которая все еще используется для работы с отдельными файлами но не цельными проектами.
На сегодняшний день код CVS содержит группа добровольцев. Интересен тот факт, что версия CVS для Microsoft Windows, отделившаяся в отдельный проект CVSNT, сейчас достаточно активно расширяет возможности системы даже портируя изменения обратно на UNIX под именем CVSNT.
Инструменты
Веб-интерфейсы
GUI-интерфейсы
Документация по CVS
Тесты
Можете проверить свои знания CVS интерактивной системой тестирования:
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
История систем управления версиями
В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список):
В VCS второго поколения появилась поддержка сети, что привело к централизованным хранилищам с «официальными» версиями проектов. Это был значительный прогресс, поскольку несколько пользователей могли одновременно работать с кодом, делая коммиты в один и тот же центральный репозиторий. Однако для коммитов требовался доступ к сети.
Третье поколение состоит из распределённых VCS, где все копии репозитория считаются равными, нет центрального репозитория. Это открывает путь для коммитов, ветвей и слияний, которые создаются локально без доступа к сети и перемещаются в другие репозитории по мере необходимости.
Хронология выхода VCS
Для контекста, вот график c датами появления этих инструментов:
SCCS (Source Code Control System): первое поколение
SCCS считается одной из первых успешных систем управления версиями. Она была разработана в 1972 году Марком Рочкиндом из Bell Labs. Система написана на C и создана для отслеживания версий исходного файла. Кроме того, она значительно облегчила поиск источников ошибок в программе. Базовая архитектура и синтаксис SCCS позволяют понять корни современных инструментов VCS.
Архитектура
Как и большинство современных систем, в SCCS есть набор команд для работы с версиями файлов:
Поскольку содержимое исходного файла теперь хранится в файле истории, его можно извлечь в рабочий каталог для просмотра, компиляции или редактирования. В файл истории можно внести изменения, такие как добавления строк, изменения и удаления, что увеличивает его номер версии.
Важно отметить, что все файлы отслеживаются и регистрируются отдельно. Невозможно проверить изменения в нескольких файлах в виде одного атомарного блока, как коммиты в Git. У каждого отслеживаемого файла свой файл истории, в котором хранится его история изменений. В общем случае это означает, что номера версий различных файлов в проекте обычно не совпадают друг с другом. Однако эти версии можно согласовать путём одновременного редактирования всех файлов в проекте (даже не внося в них реальные изменения) и одновременного добавления всех файлов. Это одновременно увеличит номер версии для всех файлов, сохраняя их согласованность, но обратите внимание, что это не то же самое, что включение нескольких файлов в один коммит, как в Git. В SCCS происходит индивидуальное добавление в каждый файл истории, в отличие от одного большого коммита, включающего все изменения сразу.
Когда файл извлекается для редактирования в SCCS, на него ставится блокировка, так что его никто больше не может редактировать. Это предотвращает перезапись изменений другими пользователями, но также ограничивает разработку, потому что в каждый момент времени только один пользователь может работать с данным файлом.
SCCS поддерживает ветви, которые хранят последовательности изменений в определённом файле. Можно произвести слияние ветви с исходной версией или с другой веткой.
Основные команды
Ниже приведён список наиболее распространенных команд SCCS.
Пример файла истории SCCS
RCS (Revision Control System): первое поколение
RCS написана в 1982 году Уолтером Тихи на языке С в качестве альтернативы системе SCCS, которая в то время не была опенсорсной.
Архитектура
У RCS много общего со своим предшественником, в том числе:
В SCCS иначе: там извлечение любой версии занимает одинаково времени. Кроме того, в файлах истории RCS не хранится контрольная сумма, поэтому нельзя обеспечить целостность файла.
Основные команды
Ниже список наиболее распространённых команд RCS:
Пример файла истории RCS
CVS (Concurrent Versions System): второе поколение
CVS создана Диком Груном в 1986 году с целью добавить в систему управления версиями поддержку сети. Она также написана на C и знаменует собой рождение второго поколения инструментов VCS, благодаря которым географически рассредоточенные команды разработчиков получили возможность работать над проектами вместе.
Архитектура
Разработчик получает копию модуля, который копируется в рабочий каталог на его локальном компьютере. В этом процессе никакие файлы не блокируются, так что нет ограничения на количество разработчиков, которые могут одновременно работать с модулем. Разработчики могут изменять свои файлы и по мере необходимости фиксировать изменения (делать коммит). Если разработчик фиксирует изменение, другие разработчики должны обновить свои рабочие копии с помощью (обычно) автоматизированного процесса слияния перед фиксацией своих изменений. Иногда приходится вручную разрешать конфликты слияния, прежде чем выполнить коммит. CVS также предоставляет возможность создавать и объединять ветви.
Основные команды
Пример файла истории CVS
SVN (Subversion): второе поколение
Subversion создана в 2000 году компанией Collabnet Inc., а в настоящее время поддерживается Apache Software Foundation. Система написана на C и разработана как более надёжное централизованное решение, чем CVS.
Архитектура
Как и CVS, Subversion использует модель централизованного репозитория. Удалённым пользователям требуется сетевое подключение для коммитов в центральный репозиторий.
Subversion представила функциональность атомарных коммитов с гарантией, что коммит либо полностью успешен, либо полностью отменяется в случае проблемы. В CVS при неполадке посреди коммита (например, из-за сбоя сети) репозиторий мог остаться в повреждённом и несогласованном состоянии. Кроме того, коммит или версия в Subversion может включать в себя несколько файлов и директорий. Это важно, потому что позволяет отслеживать наборы связанных изменений вместе как сгруппированный блок, а не отдельно для каждого файла, как в системах прошлого.
В настоящее время Subversion использует файловую систему FSFS (File System atop the File System). Здесь создаётся база данных со структурой файлов и каталогов, которые соответствуют файловой системе хоста. Уникальная особенность FSFS заключается в том, что она предназначена для отслеживания не только файлов и каталогов, но и их версий. Это файловая система с восприятием времени. Кроме того, директории являются полноценными объектами в Subversion. В систему можно коммитить пустые директории, тогда как остальные (даже Git) не замечают их.
Такая система работает только до определёного момента. Хотя дельты экономят место, но если их очень много, то на операции уходит немало времени, так как для воссоздания текущего состояния файла нужно обработать все дельты. По этой причине по умолчанию Subversion сохраняет до 1023 дельт на файл, а потом делает новую полную копию файла. Это обеспечивает хороший баланс хранения и скорости.
SVN не использует обычную систему ветвления и тегов. Обычный шаблон репозитория Subversion содержит три папки в корне:
Основные команды
Пример файла истории SVN
Git: третье поколение
Систему Git разработал в 2005 году Линус Торвальдс (создатель Linux). Она написана в основном на C в сочетании с некоторыми сценариями командной строки. Отличается от VCS по функциям, гибкости и скорости. Торвальдс изначально написал систему для кодовой базы Linux, но со временем её сфера использования расширилась, и сегодня это самая популярная в мире система управлениями версиями.
Архитектура
Git является распределённой системой. Центрального репозитория не существует: все копии создаются равными, что резко отличается от VCS второго поколения, где работа основана на добавлении и извлечении файлов из центрального репозитория. Это означает, что разработчики могут обмениваться изменениями друг с другом непосредственно перед объединением своих изменений в официальную ветвь.
Кроме того, разработчики могут вносить свои изменения в локальную копию репозитория без ведома других репозиториев. Это допускает коммиты без подключения к сети или интернету. Разработчики могут работать локально в автономном режиме, пока не будут готовы поделиться своей работой с другими. В этот момент изменения отправляются в другие репозитории для проверки, тестирования или развёртывания.
Когда ветви перемещаются в удалённые хранилища или извлекаются из них, по сети передаются эти пакетные файлы. При вытягивании или извлечении ветвей файлы пакета распаковываются для создания свободных объектов в репозитории объектов.
Основные команды
Пример блоба, дерева и коммита Git
Блоб с хэшем 37d4e6c5c48ba0d245164c4e10d5f41140cab980 :
Объект дерева с хэшем b769f35b07fbe0076dcfc36fd80c121d747ccc04 :
Коммит с хэшем dc512627287a61f6111705151f4e53f204fbda9b :
Mercurial: третье поколение
Mercurial создан в 2005 году Мэттом Макколлом и написан на Python. Он тоже разработан для хостинга кодовой базы Linux, но для этой задачи в итоге выбрали Git. Это вторая по популярности система управления версиями, хотя она используется гораздо реже.
Архитектура
Mercurial — тоже распределённая система, которая позволяет любому числу разработчиков работать со своей копией проекта независимо от других. Mercurial использует многие из тех же технологий, что и Git, в том числе сжатие и хэширование SHA-1, но делает это иначе.
Наконец, Mercurial использует ещё один тип revlog, который называется changelog, то есть журнал изменений. Это список записей, которые связывают каждый коммит со следующей информацией:
Основные команды
Пример файлов Mercurial
Журнал изменений (changelog):
Дополнительная информация об устройстве Mercurial:
Что такое cvs в тестировании
Copyright (C) 1992, 1993 Signum Support AB\* Copyright (C) 1999 Alexey Mahotkin (translation into Russian)
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation.
Перевод того же самого уведомления на русский язык (перевод, в отличие от уведомления на английском языке, законной силы не имеет):
Разрешается создавать и распространять неизмененные копии этого руководства, при условии, что на всех копиях сохраняется уведомление о копирайте и это разрешение об использовании.
Разрешается копировать и распространять измененные версии этого руководства на условиях копирования без изменений, а также при условии, что вся порожденная работа распространяется с разрешением использования, идентичному этому разрешению.
Разрешается копировать и распространять переводы этого руководства на другой язык, с точно такими же условиями использования измененных версий, за исключением того, что это разрешение может быть переведено, а перевод должен быть одобрен Фондом Свободного Программного Обеспечения.
Эта глава предназначена для людей, никогда ранее не использовавших CVS и, возможно, никогда не использовавших управление версиями.
Если вы уже знакомы с CVS и просто хотите изучить конкретную возможность или вспомнить определенную команду, вы, вероятно, можете пропустить всю главу.
Например, иногда при определенном изменении в коде могут появиться ошибки, которые вы не сможете обнаружить в течение длительного времени. С помощью CVS вы легко можете обратиться к старым версиям, чтобы точно выяснить, что именно привело к ошибке. Иногда это сильно помогает.
Конечно, вы можете хранить каждую версию каждого файла, которые вы создаете. Это будет стоить вам невероятного объема дискового пространства. CVS хранит все версии файла в одном файле таким образом, что запоминаются лишь изменения между версиями.
CVS также поможет, если вы являетесь членом группы разработчиков одного проекта. Очень легко попортить чужие изменения, если только вы не крайне аккуратны. Некоторые редакторы, такие как GNU Emacs, стараются проследить, чтобы два человека не изменяли одновременно один и тот же файл. К сожалению, если кто-то использует другой редактор, эта предосторожность не сработает. CVS решает эту проблему, изолируя разработчиков друг от друга. Каждый работает в своем собственном каталоге, а затем CVS объединяет законченные работы.
CVS появился из набора sh-скриптов, автором которых был Dick Grune, опубликованных в ньюсгруппе comp.sources.unix в томе 6 в декабре 1986 года. Несмотря на то, что ни строчки кода из тех скриптов не присутствует в CVS, основы алгоритма устранения конфликтов взяты именно оттуда.
В апреле 1989 года Brian Berliner спроектировал и реализовал CVS. Jeff Polk позднее помог ему с поддержкой модулей и ветвей поставщика.
Получить CVS можно разными способами, включая свободное получение в Интернете. За информацией о получении и по другим вопросам обращайтесь на:
В качестве введения в CVS мы приведем здесь типичную сессию работы с CVS. Первое, что необходимо понимать, это то, что CVS хранит все файлы в централизованном репозитории (see section Репозиторий); в этой главе предполагается, что репозиторий настроен.
Каталог `CVS’ используется для внутренних нужд CVS. Обычно вам не следует редактировать или удалять файлы, находящиеся в этом каталоге.
Вы запускаете свой любимый редактор, работаете над `backend.c’ и через пару часов вы добавили фазу оптимизации в компилятор. Замечание для пользователей RCS и RCCS: не требуется блокировать файлы, которые вы желаете отредактировать. See section Несколько разработчиков за объяснением.
CVS запускает редактор, чтобы позволить вам ввести журнальную запись. Вы набираете «Добавлена фаза оптимизации», сохраняете временный файл и выходите из редактора.
но лучшим способом будет использование команды release (see section Команда release: сообщить, что модуль более не используется):
Команда release проверяет, что все ваши изменения были зафиксированы. Если включено журналирование истории, то в файле истории появляется соответствующая пометка. See section Файл history.
Команда release всегда сообщает, сколько измененных файлов находится в вашей рабочей копии исходных кодов, а затем спрашивает подтверждения перед удалением файлов или внесения пометки в файл истории.
Go to the first, previous, next, last section, table of contents.
Управление исходными текстами
Часть 1. Краткое руководство по CVS
Автор: Илья Рыженков
The RSDN Group
Источник: RSDN Magazine #3
Опубликовано: 11.04.2003
Исправлено: 10.12.2016
Версия текста: 1.0.1
Введение
Необходимость управления исходными текстами
Управление исходными текстами является маленькой частью большой и сложной науки управления созданием программного обеспечения. Тем не менее, это одна из важнейших частей с точки зрения автоматизации, поскольку маленький и, в общем, несложный механизм обеспечивает информацией множество других частей общего бизнес-процесса. Управление исходными текстами имеет несколько аспектов: управление версиями, автоматическая генерация документации, поддержка единого стиля кода и контролируемые изменения. Постепенно мы раскроем все эти темы, но начнём, пожалуй, с наиболее востребованной части – управлением версиями. В этих статьях мы не будем подробно рассматривать общий подход к управлению разработкой, заинтересованных отсылаем к другим ресурсам (см. ссылки в конце статьи), однако на некоторых важных аспектах мне бы хотелось остановиться прежде, чем перейти собственно к рассмотрению темы данной статьи.
Существует множество различных точек зрения на то, каким должен быть процесс разработки программного обеспечения. Одни желают формального, тяжелого, гарантированного процесса, другим больше по душе легковесный, мобильный, рискованный процесс. Всё зависит от потребностей заказчика, компании, проекта и команды. Тем не менее, так или иначе, команда программистов создаёт код, который развивается и меняется со временем. В связи с этим можно отметить несколько фактов:
Таким образом, необходим инструмент, позволяющий централизованно хранить, получать и обновлять исходные тексты, отслеживать историю, получать версию кода по некоторым критериям и выполнять некоторые автоматические операции с кодом. Одним из таких инструментов является Concurrent Versions System (CVS).
Другие системы
Существует множество других систем для управления версиями, среди которых можно упомянуть Microsoft Visual SourceSafe, StarBase’s StarTeam и Rational ClearCase. В задачи данной статьи не входит ни сравнительный анализ этих систем, ни описание уникальных возможностей и недостатков. Если вы уже знакомы с какой-либо из систем управления версиями, постарайтесь не искать аналогий и способов сделать знакомые операции в новой среде. CVS отличается от этих систем в первую очередь концепцией использования в распределенных условиях.
Структура статьи
Если вам интересны лишь общие концепции и понимание системы как таковой – достаточно прочитать раздел «Основные понятия» и не тратить время на детали использования. В этом разделе объясняются принципы назначения версий, связь репозитория и рабочих каталогов, общий взгляд на автоматизацию процессов, а также кратко рассказано о связи CVS с другими подсистемами процесса управления исходными текстами.
Если вы собираетесь использовать CVS в своей работе, но пока не знаете, как к этому подступиться – надеюсь, что вторая часть статьи «Базовые операции» поможет вам совершить первые и последующие шаги в этом направлении. Тем не менее, очень рекомендуется прочитать и первую часть, для того, чтобы не запутаться в терминах и воспринять идеологию CVS в целом.
Основные понятия
Что такое CVS?
CVS – это система управления версиями. На самом деле, для CVS не важно, версиями чего вы управляете, однако здесь этот инструмент будет рассматриваться в том контексте, в котором он обычно используется – управление исходными текстами при разработке ПО. CVS помогает обеспечить все перечисленные во введении потребности по управлению кодом и имеет большое количество дополнительных возможностей, которыми зачастую пренебрегают. Он основан на идее центрального хранилища, с которым синхронизируются версии, используемые всеми участники проекта. Сохраняются все версии, какими мелкими бы ни были изменения. При подходе в лоб это могло бы занять неоправданно много места, однако CVS держит все версии в одном файле, сохраняя лишь изменения от версии к версии, решая, таким образом, проблему дискового пространства. Кроме того, такой подход позволяет легко сделать резервную копию всего проекта вместе со всей историей изменений.
Каждый разработчик имеет собственную копию всех исходных текстов проекта, с которыми он работает локально на своём компьютере. Разработчик вносит необходимые изменения в код, после чего помещает изменения с соответствующим комментарием в центральное хранилище, называемое репозиторием (repository). После этого остальные члены команды могут обновить свои локальные копии путем получения изменений из репозитория. Самое важное в этом процессе заключается в том, что изменения, внесенные в локальные копии, не замещаются, а совмещаются с изменениями в репозитории. Этот процесс называется merging и даёт право на слово Concurrent (одновременный) в названии инструмента. Действительно, несколько человек могут вносить изменения в одни и те же файлы одновременно и, тем не менее, не уничтожать результаты трудов друг друга.
Рисунок 1.
История
История CVS началась с нескольких скриптов, написанных Диком Грюном (Dick Grune) в декабре 1986 года. Хотя, пожалуй, ни строчки оригинального кода не сохранилось, довольно больш а я часть алгоритма разрешения конфликтов восходит к тому времени. В апреле 1989 Брайн Берлинер (Brian Berliner) придумал и разработал собственно CVS. Впоследствии ему помогал Джефф Полк (Jeff Polk) в развитии подсистем ветвей и модулей. В дальнейшем проект развивается как Open Source, его официальной web-страницей является http://www.cvshome.org.
Ограничения
CVS не является заменой управлению проектами, это всего лишь один из инструментов команды. Также этот инструмент сам по себе не содержит механизмов автоматический сборки (build system), регрессионного тестирования (regression testing), взаимодействия разработчиков (collaboration) и отслеживания ошибок (bug-tracking). Тем не менее, на базе CVS можно построить многие, если не все из этих механизмов, для получения полноценной среды разработки ПО.
При определенных усилиях автоматизация на основе CVS может давать фантастические результаты. Такая автоматизация может развиться от уведомления разработчиков об изменениях в коде по электронной почте, производимого с помощью простейшего скрипта, до проверки корректности кода, и даже прохождения тестов перед приёмом изменений в репозиторий. Другим важным свойством является свобода выбора стиля работы – CVS не навязывает никакой конкретной модели разработки. Команда может работать в том режиме, который диктуется требованиями клиента, политикой компании или взаимными договорённостями участников.
Cederqvist
Главным документом любого пользователя CVS является “Version Management with CVS”. Написанный Пэром Седерквистом (Per Cederqvist) и другими, он является «официальным» руководством де-факто. Документ, известный под кодовым именем «The Cederqvist», описывает работу с репозиторием, ветвями, файлами, резервное копирование, различные тонкости, а также содержит прочую полезную информацию. Документ доступен для скачивания с официальной страницы CVS. Перевод на русский язык доступен на странице Алексея Махоткина, автора перевода, по адресу http://alexm.here.ru/cvs-ru/cvs-ru.html
Версии файлов
В большинстве случаев пользователи CVS не сталкиваются напрямую с нумерацией версий файлов, однако для общего понимания системы и выполнения некоторых операций необходимо понимать, что является версией файла, как они меняются и что означают. Вообще говоря, в CVS не принято использовать термин «версия». Вместо него используется термин «редакция». Делается это для того, чтобы избежать возможных конфликтов с версией продукта как целого (например, Microsoft Explorer версии 6), версией изменения (относится к управлению изменениями и в данной статье не обсуждается) и тому подобных проблем. Мы тоже будем придерживаться этой практики в нашей статье, и, хотя кое-где и будет употребляться слово «версия», оно никогда не будет относиться к «редакциям» файлов.
Что же такое редакция файла? В процессе работы над проектом файлы претерпевают изменения, добавляются новые и исчезают ненужные. Редакцией называется зафиксированное в репозитории (центральном хранилище файлов) состояние файла. Изменения файлов в рабочем каталоге не создают новых редакций, сколько бы дней или даже месяцев вы над ними не работали. Редакция появляется тогда, когда вы отправляете изменения в репозиторий. Самая первая редакция появляется при добавлении файла в репозиторий и получает номер 1.1. Вообще, в CVS все редакции имеют чётное количество десятичных чисел, разделённых точками. Более подробно формирование номера редакции мы рассмотрим позже, в части посвящённой ветвям, а пока будет считать, что это два десятичных числа, разделенных точкой. При создании новой редакции последнее число увеличивается на единицу:
Рисунок 2.
Кроме цифровых номеров редакций, которые для простоты можно рассматривать как внутренний механизм CVS, можно использовать и символические имена. Вы можете присвоить символическое имя отдельной редакции отдельного файла, группе файлов или всему проекту сразу. Для выполнения этой функции используются «метки» (tags), которые подробно обсуждаются во второй части статьи при описании работы с редакциями и в третьей части при описании управления ветвями.
Репозиторий
| ПРЕДУПРЕЖДЕНИЕ Рабочий каталог – не то же самое, что репозиторий, и он не может быть подкаталогом репозитория. И наоборот, репозиторий не может находиться в подкаталоге рабочего каталога. В противном случае последствия непредсказуемы. Например, если ваш репозиторий находится на локальном или сетевом диске, вы можете использовать метод доступа local. Тогда CVSROOT будет выглядеть так (для Windows): Обратите внимание, что для Windows слэши всё равно должны быть прямыми, а не обратными, как это принято в самой операционной системе. Кроме того, в CVS имена файлов чувствительны к регистру символов (case sensitive), тогда как Windows игнорирует регистр. Это может привести к проблемам, если у вас в репозитории находятся файлы File.h и file.h. Старайтесь использовать нижний регистр для имен файлов при работе с Windows. Примеры CVSROOT с комментариями: Совмещение и обновлениеCVS всегда помнит, какие редакции у вас находятся в рабочем каталоге. Для изменённых файлов он помнит, какие редакции у них были до того, как вы начали изменять эти файлы. Это необходимо, чтобы правильно совместить несколько изменений, произошедших с файлом одновременно. Предположим, что два разработчика одновременно начали работать над одним и тем же файлом, и в момент начала этого процесса в репозитории была редакция 1.1. По истечении определенного времени мы имеем в репозитории редакцию 1.1 и в двух рабочих каталогах изменения к этой редакции. Предположим также, что работа в каталоге №2 закончена и изменения отправляются в репозиторий (детали этой операции мы рассмотрим в следующей части статьи). В репозитории появляется новая редакция файла и ей присваивается номер 1.2. В каталоге №2 тоже содержится редакция 1.2. Однако в каталоге №1 по-прежнему находятся изменения относительно редакции 1.1. Теперь, если мы захотим отправить изменения в репозиторий из рабочего каталога №1, система откажет нам в операции, поскольку каталог №1 устарел и сформировать редакцию 1.3 в репозитории невозможно. Поэтому каталог №1 необходимо сначала обновить, при этом произойдёт совмещение (merge) редакций. Иными словами, изменения от 1.1 до 1.2, имеющиеся в репозитории, будут применены к файлу в рабочем каталоге. При этом изменения, сделанные локально, не пропадают и, в результате, в рабочем каталоге оказывается редакция 1.2 с изменениями, сделанными локально. Теперь можно спокойно отправить файл в репозиторий и получить редакцию 1.3, в которой наличествуют изменения, сделанные в обоих рабочих каталогах. Для полного завершения картины мы должны обновить каталог №2 (там по-прежнему находится редакция 1.2) до редакции 1.3, имеющейся в репозитории. Всё ли так гладко и замечательно, как кажется на первый взгляд? В большинстве случаев – да. Однако существуют моменты, когда в процессе совмещения редакций возникает ситуация, при которой CVS не может самостоятельно решить вопрос о слиянии. Например, если в предыдущем примере в обоих рабочих каталогах был исправлена одна и та же строчка, но по-разному. Вообще говоря, для CVS важно, чтобы изменения были достаточно далеко друг от друга. Тогда процесс совмещения происходит автоматически. Если же изменения слишком близки, возникает конфликт, который необходимо разрешить вручную прежде, чем продолжать работу. Более подробно о конфликтах рассказывается в пункте «Разрешение конфликтов» второй части статьи. Базовые операцииПодготовка к работеУстановкаИсполнение командОбщий синтаксис операций с CVS выглядит так: Угловой скобкой в начале строки «>» я буду отмечать текст, набираемый в командной строке. Текст без угловой скобки, следующий за командой, является предполагаемым выводом. Иными словами, после имени исполняемого модуля идут опции, общие для всех команд и определяющие функционирование системы в целом, а после имени команды – опции, определяющие поведение этой команды, и специфичные для команды аргументы. Ниже приводится список ключей для CVS.
|
