ArcaOS 5.0 Русская версия Пакет русификации ArcaOS 5.0 OS/2 давно доступен. Поддерживается любая версия: 5.0, 5.0.1, 5.0.2. eCo Software может выпустить и другие пакеты (Немецкий, Голландский, Бразильский Португальский, Испанский, Шведский и т.д.)

TITLE: Как работать с jCVS

DATE: 2002-01-26 00:28:34

AUTHOR: Dmitry Froloff

Данная заметка не претендует на полноту и обстоятельность, и ни в коей мере не является заменой оффициальных руководств по CVS и JCVS. Системным администраторам также следует обратить внимание на вопросы безопасного использования CVS (рассматриваются в руководстве по CVS).

В начале приведу выдержку из руководства по CVS, любезно переведённого для нас Алексеем Махоткиным.

Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994 Free Software Foundation, Inc.

Перевод на русский язык Copyright (C) 1999-2000 Alexey Mahotkin

Что такое CVS?

Не помнящие прошлого обречены повторять его - Джордж Сантаяна

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

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

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

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

Чем не является CVS?

CVS сделает для вас множество вещей, но не пытается быть всем сразу.

CVS не является системой управления сборкой.

Несмотря на то, что структуры вашего репозитория и файла модулей взаимодействуют с системой управления сборкой (то eсть файлами `Makefile'), они принципиально независимы.

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

CVS не указывает, как использовать дисковое пространство в извлеченных каталогах. Если вы создадите `Makefile' или скрипты в каждом каталоге так, что они должны знать относительную позицию всего остального, то дело кончится тем, что придется извлекать весь репозиторий.

Если вы модуляризуете вашу работу и создадите систему сборки, которая будет совместно использовать файлы, (посредством ссылок, монтирования, `PATH' в `Makefile''ах и т. д.), то сможете использовать дисковое пространство любым угодным вам способом.

Помните только, что любая подобная система требует серьезной работы по созданию и поддержанию. CVS не пытается справиться с возникающими при этом вопросами.

Конечно же, вам следует поместить средства, созданные для поддержки системы сборки (скрипты, `Makefile''ы, и т. д.), под CVS.

Выяснение того, какие файлы следует перекомпилировать при каком-либо изменении, опять же, не является задачей CVS. Традиционным подходом является использование `make' для сборки, и использование специальной утилиты для генерации зависимостей, используемых программой `make'.

CVS не является заменой руководителю

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

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

CVS не является заменой общения разработчиков.

Встретившись с конфликтом, состоящим из единственной строки, большинство разработчиков справляются с ними без особого труда. Однако, более общее определение "конфликта" включает в себя проблемы, которые слишком трудно решить без взаимодействия разработчиков.

CVS не может обнаружить, что синхронные изменения в одном или нескольких файлах привели к логическому конфликту. Понятие "конфликт", которое использует CVS, строго текстуально. Такие конфликты появляются, когда изменения в основном файле достаточно близки, чтобы напугать программу слияния (то есть `diff3').

CVS совершенно неспособна помочь в устранении нетекстуальных или распределенных конфликтов в логике программы.

Пример: предположим, вы изменили аргументы функции `X', описанной в файле `A'. В то же самое время кто-то еще редактирует файл `B', добавив новый вызов функции `X', используя старые аргументы. CVS ничем не сможет помочь.

Возьмите привычку читать спецификации и беседовать с коллегами.

CVS не ведет контроля изменений

Под "контролем изменений" имеется в виду несколько вещей. Во-первых, это может означать "отслеживание ошибок", то есть хранение базы данных обнаруженных ошибок и состояние каждой (исправлена ли она? в какой версии? согласился ли обнаруживший ее, что она исправлена?). О взаимодействии с внешней системой отслеживания ошибок можно прочитать в файлах `rcsinfo' и `verifymsg' (Административные файлы).

Другим аспектом контроля изменений является отслеживание того факта, что изменения в нескольких файлах в действительности являются одним и тем же согласованным изменением. Если вы фиксируете несколько файлов одной командой `cvs commit', то CVS забывает, что эти файлы были зафиксированы одновременно, и единственная вещь, их объединяющая - это одинаковые журнальные записи. В данном случае может помочь ведение файла `ChangeLog' в стиле GNU.

Еще одним аспектом контроля изменений, в некоторых системах является возможность отслеживать статус каждого изменения. Некоторые изменения были написаны разработчиком, некоторые были изучены другим разработчиком, и так далее. Обычно при работе с CVS в этом случае создается diff-файл, (используя `cvs diff' или `diff'), который посылается по электронной почте кому-нибудь, кто потом применит этот diff-файл, используя программу `patch'. Это очень гибко, но зависит от внешних по отношению к CVS механизмов, чтобы убедиться, что ничего не упущено.

CVS не является системой автоматического тестирования

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

CVS не имеет встроенной модели процесса

Некоторые системы обеспечивают способы убедиться, что изменения и релизы проходят через определенные ступени, получая одобрение на каждой. Вообще говоря, этого можно добиться с помощью CVS, но это может потребовать немного больше работы. В некоторых случаях вы будете использовать файлы `commitinfo', `loginfo', `rcsinfo' или `verifymsg', чтобы убедиться, что предприняты определенные шаги, прежде чем CVS позволит зафиксировать изменение. Подумайте также, должны ли использоваться такие возможности, как ветви разработки и метки, чтобы, скажем, поработать над новой веткой разработки, а затем объединять определенные изменения со стабильной веткой, когда эти изменения одобрены.

Более детально ознакомиться с функционированием CVS можно прочитав руководство в формате html или txt.

Нашей задачей будет настроить JCVS так, чтобы этим замечательным средством стало легко и удобно пользоваться. Для этого нам потребуется jcvs.zip (можно скачать отсюда) и cvs111.zip (ищите на hobbes).

Итак, прежде всего необходимо задать местонахождение репозитория, где CVS будет хранить результаты наших трудов. Это может быть любой компьтер, под управлением OS/2, видимый всеми остальными через протокол TCP.

Создаём на нём для CVS корневую директорию (например C:\cvsroot).

Из архива cvs111.zip нам потребуется cvs.exe и cvspw.exe. Положим их в директорию, заданную в PATH (у меня они находятся в \OS2\APPS).

Инициализируем CVS.

CVS -d:local:C:\cvsroot init 

В результате в директории c:\cvsroot будет создана служебная директория CVSROOT.

Далее настраиваем суперсервер inetd (если он не запускается по умолчанию, то необходимо настроить TCPIP, изложение будет вестить в предположении, что используется 32 битный TCPIP, иначе соответсвующие файлы могут находиться в других директориях).

Проверим, что файл \mptn\etc\services содержит строку

cvspserver      2401/tcp    #cvspserver

В файл \mptn\etc\inetd.lst добавляем строку

cvspserver tcp cvs -f --allow-root=/cvsroot  pserver

Здесь /cvsroot должно соответствовать директории заданоой в команде cvs init.

После этого нужно перезапустить inetd, чтобы изменения воспринялись.

Для авторизации пользователей в директории \cvsroot\CVSROOT создаём файл passwd. В этом нам поможет утилита cvspw.exe.

cvspw -add <Имя пользователя> <пароль>

Настройка репозитория и сервера cvs завершена.

Для функционирования JCVS клиента необходима сконфигурированная и настроенная java версии 1.1 (у меня Java 1.1.8).

На клиентских компьтерах распаковываем архив jcvs.zip, например, в директорию C:\JCVS.

Для запуска удобно использовать командный файл jcvs.cmd. И запускать его через программный объект рабочего стола.

После запуска увидим:

Прежде всего необходимо, удостовериться, что JCVS успешно устанавливает соединение с сервером, в этом нам поможет закладка Test.

Заполняем поля User Name и Password в соответствии с заданными с помощью программы cvspw, указываем имя компьтера, где выполняется сервер cvs, корневую директорию репозитория CVS и проверяем правильность подключения.

К сожалению, JCVS не умеет (или мне не удалось её заставить) работать с репозиторием в локальном режиме, поэтому в этом случае укажите в качестве CVS Server localhost.

Создание проекта рассмотрим на примере.

Для создания проекта служит закладка Create.

После этого выберем закладку Checkout и выполним Checkout Module.

В результате откроется пока пустое окно проекта.

В директории D:\projects\test создадим файл test.c и добавим его в проект.

CVS сообщит нам:

После этого в окне проекта появится добавленный файл.

Для фиксирования изменений в репозтории воспользуемся:

После этого откроется окно в котором можно сохранить/прокомментировать суть сделанных изменений с этим файлом.

>Не жалейте времени - пишите комментарии, а не отписки. Не следует, например, писать: добавлена процедура test1(void). Это и так легко можно увидеть с помощью команды diff!

CVS сообщит нам об успешном выполнении операции:

Через меню File добавим проект в Workbench.

Теперь при следующем запуске JCVS, при открытии проекта test будет выполняться подключение к серверу с запросом пароля.

Имеется также возможность создать проект на базе существующего набора исходных текстов.

В этом поможет закладка Import

Здесь можно отметить файлы, которые следует игнорировать (lst, obj, lib) и файлы, которые добавляются в репозиторий как двоичные.

На этом можно первое знакомство с JCVS можно считать состоявшимя.

Автор надеется, что эта небольшая заметка поможет разработчикам программного обеспечения (и не только им) успешно принять CVS к себе на службу.

Комментарии:

Сергей 2002-01-29 08:55:03	На каком CVS-сервере можно найти осевой софт? Куда можно выкладывать свой?
Deniska 2002-01-29 23:21:51	вот как раз недавно была новость об этом - скоро будут выложены материалы по этому поводу - а пока можно воспользоваться этой ссылкой [url]

Прокомментируйте эту статью (напоминаем, автор работал над текстом несколько недель, уважайте мнение других).

Ваше имя: Ваш E-Mail: CODE:
Ваш комментарий:

eCS 2.0 наполнена драйверами для современных устройств. Поддержка современных материнских плат, сетевых адаптеров и видеокарт. Всё настраивается автоматически. Что нового в eCS 2.0?