• Структура и функционал продукта
• Проект TeamSource
• Хранилище TeamSource
• Версии проекта и отдельных его составляющих
• Управление проектом
• Оповещение об изменениях в проекте

TeamSource представляет собой хост-приложение, функционал которого построен на принципе использования подключаемых модулей (plug-ins), разрабатываемых на основе специальных API, поставляемых в составе продукта. Все операции над элементами (файлами) проекта осуществляются при помощи так называемых контроллеров, посредством которых осуществляется как доступ к хранилищу версий файлов проекта, генерация и обработка номеров версий файлов, заполнение комментариев к файлам и проектам, а также многие другие операции. Контроллеры располагаются в подключаемых модулях расширения. Эти модули имеют расширение имени файла .tsx (TeamSource eXtension). В базовую поставку входят модули izlib.tsx —базовый контроллер версий, осуществляющий хранение версий файлов проекта в библиотеках формата ZLib (формат совместим с ZIP, однако в отличие от последнего не является собственностью какой-либо компании, а потому не требует лицензионных отчислений за использование в программных продуктах) и tscomments.tsx — контроллер ввода комментариев к файлам и проектам.

Проект TeamSource

Проект TeamSource включает в себя секцию глобальных параметров проекта, таких, как название проекта, корневой каталог для размещения хранилища версий, список участников проекта (имена пользователей и пароли), права доступа к проекту и некоторые управляющие параметры контроллера для версий, а также секцию описания компонентов программного проекта, контроль версий которого осуществляется TeamSource. В секцию описания входит перечень каталогов, в которых размещаются подлежащие контролю файлы, для каждого из которых имеется возможность задать набор масок файловых имен для фильтрации, как инклюзивной так и эксклюзивной. Также для каждого из каталогов можно задать список нижележащих каталогов, которые будут обрабатываться вместе со своим родительским каталогом. Проект TeamSource также подразделяется на локальную и удаленную части (Local и Remote), причем удаленная часть на самом деле является хранилищем версий, но для удобства интегрирована в единый интерфейс. Соответственно, параметры для локальной обработки, такие, как список каталогов, фильтры и данные о последних операциях Check-In и Pull, актуальные только для конкретной рабочей станции, хранятся в файлах имя_проекта.tsl и имя_проекта.tsr, располагающихся в корневом каталоге программного проекта (первом в списке каталогов в проекте TeamSource), а параметры удаленной части — в подкаталоге Archives корневого каталога хранилища версий (смотри раздел "Хранилище TeamSource"). Список проектов TeamSource и список каталогов, участвующих в этих проектах хранится в системном реестре в ключе HKEY_CURRENT_USER\Software\Borland\TeamSource\1.0\Projects.

Хранилище TeamSource

Хранилище TeamSource организовано таким образом, что для каждого нового проекта выделяется определенный корневой (root) каталог, внутри которого создается структура подкаталогов и файлов, соответствующая файлам и каталогам, включенным в описание проекта. Изначально для каждого корневого каталога создается следующая структура файлов и подкаталогов:

В каталоге Archives хранятся архивы в формате ZLib, содержащие все версии каждого из файлов проекта. Для именования этих архивов используется следующая схема: к имени исходного файла вместе с расширением добавляется расширение .z, то есть файл с именем test.pas будет помещен в архив test.pas.z. Таким образом достигается сохранение структуры проекта и повышается надежность хранения данных, поскольку во-первых не существует отдельно хранимого оглавления, разрушение которого может привести к утере всех версий файлов проекта, а во-вторых даже в случае повреждения отдельных архивов не будет затронут весь проект. Также в этом каталоге размещаются два файла: имя_корневого_каталога.cpj и имя_корневого_каталога.version. Первый содержит информацию о проекте: имя проекта, отображаемое в различных элементах интерфейса TeamSource, версию продукта TeamSource, которым было создано данное хранилище версий проекта, а также уникальное имя контроллера версий, получаемое от соответствующего модуля расширения. Второй содержит версию проекта, которая будет помещаться в ресурс VERSIONINFO, который TeamSource имеет возможность создавать в определенном каталоге с исходными текстами проекта для дальнейшего использования при сборке этого проекта. Начальное значение версии может быть задано вручную, для этого следует создать соответствующий файл в любом текстовом редакторе и сохранить его в формате ASCII. Формат этого файла приведен в справочном файле TeamSource.

В каталоге History хранятся файлы истории сеансов работы TeamSource с данным проектом. Имена файлов формируются по внутреннему алгоритму TeamSource и имеют вид <код_даты_времени>.Имя_Рабочей_Станции. Дата и время кодируются TeamSource, имя рабочей станции берется из параметров сеанса операционной системы. Таким образом, каждый файл истории имеет примерно такое имя: CI090901.Nikita. Файл истории содержит имя пользователя, работавшего с проектом, дату и время сеанса, а также список затронутых различными операциями файлов.

В каталоге Locks находится, как правило, единственный файл с именем lockinfo.dat, содержащий информацию о блокировках для данного проекта.

Версии проекта и отдельных его составляющих

Версии проекта и его составляющих назначаются соответствующей функцией контроллера TeamSource. Базовый контроллер формирует версию каждой из составляющих проекта при помещении ее в хранилище, увеличивая на единицу правую часть двойного значения версии, исходное значение которой (для самой первой версии файла, помещенной в хранилище) равно 1.0. Когда правая часть достигает значения 99, левая увеличивается на единицу, а правая —приравнивается к нулю. Этот алгоритм является общепринятым при формировании идентификаторов версий файлов. Однако Вы можете реализовать свой собственный генератор версий, создав специальное расширение TeamSource на основе специального API (модуль IVAPI.pas в каталоге Sources из поставки TeamSource).

Версия проекта задается при его описании и не генерируется автоматически. Однако существует возможность задания версии проекта вручную. Смотри раздел "Хранилище TeamSource".

Для специальной отметки отдельных версий проекта, например полностью отлаженных или находящихся на какой-либо иной стадии разработки, в TeamSource применяется операция установки закладки (Bookmark). Установка закладки специальным образом помечает текущую версию всех составляющих проекта, что позволяет затем выполнить операцию Pull или Check-Out всего проекта не выбирая каждую отдельную составляющую требуемой версии, а выбрав необходимую закладку из списка. Поскольку закладка снабжается комментарием, нетрудно внести в его текст соответствующую информацию о помеченной версии проекта и другие необходимые сведения. Также имеется возможность заменить одну версию составляющей проекта другой, оставив признак закладки неизменным, что позволяет вносить отдельные изменения в уже помеченный какой-либо закладкой проект. Составляющие проекта, помеченные закладкой, могут также быть приняты в качестве последней актуальной версии при помощи специальной процедуры.

Актуальной версией (или Tip Revision) в TeamSource принято считать совокупность самых новых ("младших") версий составляющих проекта. Например, если в нашем проекте имеется три составляющих: Main.pas версий 1.0, 1.1. и 1.2, Main.dfm версий 1.0 и 1.1, DemoProject.dpr версий 1.0, 1.1 и 1.2, то актуальной версией проекта (и составляющих) будут являться: Main.pas 1.2, Main.dfm 1.1, DemoProject 1.2.

Каждую из версий отдельной составляющей проекта можно сделать актуальной или переназначить версию при помощи специальных действий, описанных в разделе "Работа с хранилищем версий (Remote)".

Управление проектом

Управление проектом в TeamSource осуществляется через пользовательский интерфейс хост-приложения, по внешнему виду напоминающий Microsoft Outlook. При запуске предварительно настроенного TeamSource после выбора существующего или создания нового проекта, интерфейс переходит в информационный режим (Info):

Рисунок 1. Интерфейс TeamSource в режиме Info.

Для управления проектом используются три представления, перечисленные в панели слева: History (режим отображения истории обработки версий составляющих проекта), Remote (режим работы с хранилищем версий, операций Pull, Check-Out и так далее) и Local (режим работы с локальными копиями составляющих проекта, операций Check-In). Более подробно вышеперечисленные режимы рассматриваются в разделе "Основные этапы работы с TeamSource".

Управление версиями проектов в TeamSource реализовано по отличной от принятой в большинстве PVCS. Как правило, большинство из существующих PVCS обеспечивают разрешение конфликтов версий за счет хранения всех версий составляющих проекта в центральном хранилище и блокировки отдельных версий при выполнении процедуры Check-Out до повторного выполнения Check-In. Такая схема достаточно надежна и во многих случаях оправдывает себя, поскольку в во многих группах, разрабатывающих программное обеспечение, применяется такое разделение труда, при котором каждый отдельно взятый разработчик занят отдельным модулем и блокировка модуля при операции Check-Out не приведет к каким-либо проблемам, поскольку для чтения остается доступной последняя актуальная версия составляющей проекта, а вносить в нее изменения может только один разработчик. Однако подобная схема далеко не всегда работоспособна, поскольку если мы вернемся к примеру из раздела "Разрешение конфликтов (Conflict Resolving)", то обнаружим, что даже при условии снятия проблемы конфликта версий метод блокировки в достаточно большой степени затрудняет процесс разработки постоянным наличием запрещенных к модификации и даже получению для просмотра текущей версии той или иной составляющей проекта, что зачастую просто недопустимо.

Для осуществления управления версиями проекта в иерархии участников выделяется администратор или Root User, который будет обладать полным набором прав по отношению ко всему проекту TeamSource: создавать хранилища и локальные копии, осуществлять полную блокировку проекта, менять текущую актуальную версию проекта, устанавливать права доступа к проекту других его участников и так далее. Каждый пользователь может быть также обеспечен паролем для доступа к проекту, однако это не является обязательным условием, тогда как Root User по понятным причинам всегда должен иметь пароль для доступа к проекту.

Оповещение об изменениях в проекте

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

Во многих промышленных PVCS подсистема оповещения вынесена в отдельный модуль, который, кстати, может иметь значительно большую стоимость нежели сама PVCS. Например, в Intersolv (Merant) PVCS подсистема оповещения реализована в отдельном модуле PVCS Notifier, не входящем в базовую поставку. В тоже время, этот модуль может использоваться как отдельный продукт, поскольку представляет собой реализацию списка рассылки, снабженного развитыми механизмами перекрестных связей и установки приоритетов. Однако в контексте контроля версий программных проектов многие из его возможностей оказываются невостребованными, тогда как эксплуатация значительно усложнена за счет наличия этих самых возможностей, требующих специальной настройки или, по крайней мере, отключения.

Существует и другой, "зеркальный" подход, заключающийся в отказе от подсистемы оповещения вообще или реализации ее на уровне вызовов MAPI (Mail API), что характерно для платформы WIN32.

Продолжение статьи

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме Inprise/Borland