Еще три-четыре года тому назад термин "система контроля версий проекта" лично в моем сознании ассоциировался с крупными фирмами-производителями программного обеспечения, группами из десятков программистов и миллионами строк исходного кода и даже постепенное вхождение в обиход термина RAD (Rapid Application Development, быстрая разработка приложений) практически не влияло на такую ассоциативную связь, поскольку становление таких средств RAD, как Delphi, а затем С++ Builder и JBuilder только начиналось и практически никто из сегодняшних разработчиков, создавших к настоящему моменту огромное число приложений различной степени сложности, состоящих из тех самых миллионов строк исходного кода, еще не представлял себе тех проблем, которые наряду с неоспоримыми преимуществами привнесли в разработку программного обеспечения RAD-инструменты. Одной из таких проблем стал стремительный рост числа не только модулей исходного кода, но и полноценных проектов, поддерживаемых зачастую одним единственным разработчиком. Средства RAD позволили осуществлять практически полный цикл разработки программного обеспечения значительном меньшими группами людей, нежели это было раньше, значительно повысив производительность как отдельных разработчиков, так и рабочих групп, занятых на том или ином проекте. Рост производительности разработчиков, имевший взрывной характер, что было обусловлено значительным снижением времени, затрачиваемого как на обучение работе со RAD-инструментом, так и на выполнение собственно поставленных перед разработчиком задач, быстро привел к достаточно закономерной перегрузке проектами, исходным кодом и документацией отдельных разработчиков и их групп, заставив многих пересмотреть свои подходы к организации процесса создания программного обеспечения.

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

За короткое время системы контроля версий проектов (Project Version Control Systems, PVCS, не путать с торговой маркой Intersolv PVCS компании Merant) вышли из относительно узкой ниши крупных компаний-производителей программного обеспечения как за счет снижения сложности в использовании, так и за счет значительного (на порядки) снижения стоимости подобных систем и значительного расширения выбора среди классов и продуктов данной категории. Однако до недавнего времени большинство производителей PVCS по инерции ориентировались на крупные компании-производители ПО, или же старались использовать уже имеющиеся наработки, что зачастую приводило к оголению отдельных секторов рынка подобных систем. Живым примером тому может служить практически полное отсутствие до недавнего времени PVCS-продуктов, поддерживающих Delphi и язык Object Pascal (очевидно за счет того, что большинство проектов, использовавших различные PVCS, ранее велось на языке C/C++, а в США еще и на COBOL и ему подобных). Мои личные изыскания на этом фронте велись практически с начала работы с Delphi (1995 год), однако первые, действительно годные к использованию в проектах как одним человеком, так и группой разработчиков, продукты стали появляться лишь где-то в 1997/98 годах (я не имею в виду Lite-версию Intersolv PVCS, встроенную в Delphi 3 Professional и C/S edition, поскольку эта версия являлась скорее переходным средством к "полноценной" версии Intersolv PVCS). Ориентированные же на Delphi системы, обладающие возможностью подключения в виде расширений и экспертов к среде разработки (IDE) Delphi и C++ Builder, полностью использующие возможности Open Tools API, появились лишь в конце 1998 — начале 1999 года (например FreeVCS, система контроля версий проектов для Delphi 4, разработанная Томасом Хенсле (Thomas Hensle, http://www.thensle.de/index.htm)). Поэтому на фоне некоторой неразберихи с продуктами PVCS заметным событием стало появление в составе Delphi5 системы контроля версий проектов, разработанной, а главное, используемой, инженерами Borland в их собственных проектах.

Наверное, я не погрешу против истины утверждая, что продукт, созданный разработчиками для разработчиков скорее всего будет обладать теми самыми возможностями, содержать какие-то "изюминки", которых Вам как раз-таки не хватало все то время, пока в нашем с вами распоряжении не появился этот замечательный во всех смыслах продукт: Borland TeamSource.

Немного теории

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

Система контроля версий проекта

Системой контроля версий проектов (Project Version Control System, PVCS) называется комплекс программного обеспечения, назначением которого является централизованное хранение и обработка всех или большей части объектов (файлов), из которых состоит проект некоего программного продукта.

Проект

Под проектом понимается вся совокупность файлов исходных текстов различных языков программирования, ресурсных и других файлов, необходимых для сборки программного продукта (одного или более исполняемых файлов, библиотек DLL и так далее). Часто к вышеперечисленному добавляются исходные тексты файлов справки (Help files), сценарии программ инсталляции, а также сопроводительная документация проекта и так далее.

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

Версия проекта

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

Контроль (управление) версиями проекта

Контроль версий проекта является основной задачей PVCS. В общем виде схема работы PVCS выглядит следующим образом:

Общий вид схемы контроля версий проекта с использованием PVCS.

Основными процессами в эксплуатации PVCS являются:

· Ввод первичной информации о проекте, его структуре и составляющих. Создание первой копии проекта в хранилище PVCS.

· Настройка PVCS для работы с данным проектом: определение участников проекта, задание паролей и прав доступа к тем или иным составляющим (чтение, модификация, удаление и т.д.) и к ко всему проекту, определение перекрестных связей составляющих проекта, определение владельцев тех или иных составляющих.

· Ввод (Check-In) в контроллер версий PVCS модифицированных (или вновь созданных) составляющих проекта для помещения их в центральное хранилище версий с присвоением номера версии составляющей и проекта.

· Выдача (Check-Out) отдельных составляющих проекта для модификации с проверкой прав доступа и возможностью блокировки получения копии этой версии составляющей другим участником проекта до момента помещения модифицированной версии в хранилище.

· Выдача всех составляющих проекта (Pull) заданной версии для сборки программного продукта или отдельного его компонента.

При этом могут использоваться такие сервисные функции, как:

· Оповещение участников проекта об изменениях и действиях над проектом (Notification).

· Создание конфигурации для компиляторов с языков разработки для сборки проекта по его структуре (Configuration building).

· Автоматическая сборка заданной версии проекта (Project building).

· Защита заданной финальной версии проекта от дальнейшей модификации (Version/Project Locking).

· Помещение информации о версии составляющей и проекта (Version Info Embedding) в общий ресурсный файл или прямо в файл элемента проекта для дальнейшего использования при сборке (создание ресурса VERSIONINFO) или же для визуального контроля.

· Автоматическое создание нового идентификатора (Version ID Generation) версии составляющей или всего проекта как в процессе Check-In, так и при автоматической сборке проекта (Project building) или установке идентификатора версии проекта или его составляющей.

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

Хранилище PVCS

В качестве хранилища составляющих проектов различные системы PVCS используют множество технологических решений начиная с файлово-каталожной схемы на выделенном носителе и заканчивая специальными базами данных на платформе тех или иных СУБД. Некоторые PVCS позволяют использовать несколько способов хранения одновременно, используя, например, СУБД для хранения оперативных копий текущей (находящейся в разработке и отладке) версии проекта, а накопитель на магнитной ленте типа DAT — для резервирования и хранения более ранних, уже законченных версий.

Блокировка отдельных составляющих и проекта в целом (Version/Project Locking)

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

Итак, мы рассмотрели основные понятия и этапы использования PVCS при разработке программных проектов. Замечу, что во многих случаях PVCS вполне возможно использовать не только для контроля версий программных проектов и их составляющих, но и для контроля версий как различных сопроводительных документов к этим проектам, так и не связанных с ними напрямую файлов, например документов службы технической поддержки, поскольку в большинстве PVCS имеется возможность определения пользовательских типов файлов для помещения в хранилище. Поэтому сфера применения PVCS отнюдь не ограничивается только лишь разработкой программного обеспечения, однако это направление является наиболее важным и все системы PVCS ориентированы в первую очередь на работу с исходными текстами на различных языках программирования, бинарными файлами ресурсов и другими типами файлов, для которых заранее известна их структура и могут быть предусмотрены различные стандартные схемы обработки, например помещение идентификатора версии в текстовый (ASCII) файл с исходным кодом на языке программирования для визуального контроля.

Разрешение конфликтов (Conflict Resolving)

Рассмотрим следующий пример: разработчик A1 из проекта A занимается разработкой внутренней библиотеки A_Library.pas совместно с разработчиком A2. A1 получает копию A_Library.pas и в течении одной рабочей недели занимается реализацией некоторой достаточно объемной части исходного кода внутри этой библиотеки. В некий момент времени, когда разработчик A1 занят своей частью работы, разработчик A2 получает свою копию A_Library.pas с целью внести изменения в свою часть библиотеки. Закончив работу, он передает новую версию на вход PVCS, однако разработчик A1 еще не закончил свою часть изменений в библиотеке. В результате возникает конфликт, поскольку как изменения, внесенные разработчиком A2, так и A1 равно важны для проекта. Разрешить конфликт в данном случае можно было бы добавлением исходного кода, созданного разработчиком A1 в версию модуля от A2 или наоборот, однако в реальной жизни этот вариант по понятным причинам оказывается нежизнеспособен.

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

· Блокировка версии компонента проекта при операции Check-Out до повторного Check-In;

· Блокировка модификации компонента проекта кем-либо кроме ответственного разработчика;

· Разрешение модификации компонента проекта всеми разработчиками, имеющими к нему доступ, с сохранением каждого нового варианта компонента проекта под новой внутренней версией с переходом к разрешению конфликта в интерактивном режиме при условии наличия конфликта даты и времени модификации компонента проекта (дата и время закладываемой в хранилище PVCS версии старше, чем дата и время последней уже сохраненной версии).

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

Что такое система TeamSource

TeamSource — это система контроля версий проектов (PVCS), предназначенная для управления версиями проектов, разрабатываемых с использованием Borland Delphi и Borland C++ Builder. TeamSource была изначально разработана для сопровождения проектов на Delphi и C++ Builder, в связи с чем не несет "тяжкого груза наследственности" PVCS исключительно для работы с C/C++, характерного для многих других PVCS. Более того, в силу характерного для всех инструментов, создаваемых в компании Inprise, гибкого подхода к решению поставленных задач, TeamSource может быть совершенно "прозрачно" использована для хранения и контроля версий файлов, не связанных со средствами разработки, например документов MS Word или любых других. Если же Вы используете в своем проекте помимо средств разработки Borland/Inprise инструменты других фирм или же свои собственные, в TeamSource имеется возможность создания расширений (контроллеров) на основе соответствующих API (Application Programming Interface, прикладных программных интерфейсов), позволяющих обрабатывать такие элементы проектов точно так же, как и предопределенные в поставляемых с TeamSource контроллерах.

TeamSource изначально является средством групповой разработки, однако может использоваться и в однопользовательском режиме, поскольку не имеет жесткой привязки к каким-либо сетевым средствам или протоколам.

При работе в группе, TeamSource решает большинство из перечисленных в разделе "Немного теории" задач, включая оповещение (Notification) и разрешение конфликтов (Conflict Resolving).

Базовое хранилище версий TeamSource реализовано по файлово-каталожному принципу, однако существует возможность использовать хранилище и контроллер версий системы Merant PVCS (бывший Intersolv PVCS) за счет подключения специального расширения, поставляемого с TeamSource. Также имеется возможность написания собственного расширения для управления хранилищем версий, например для использования в качестве хранилища базы данных SQL-сервера IB DataBase компании InterBase Software.

В этой связи необходимо упомянуть, что TeamSource поставляется вместе с исходными текстами самого приложения TeamSource и его модулей расширения, а также с API для написания этих расширений, что позволяет досконально изучить устройство продукта с тем, чтобы максимально полно использовать его возможности при создании собственных дополнений к 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) каталог, внутри которого создается структура подкаталогов и файлов, соответствующая файлам и каталогам, включенным в описание проекта. Изначально для каждого корневого каталога создается следующая структура файлов и подкаталогов:

Таблица 1. Базовая структура каталогов и файлов для хранилища TeamSource

<Dir> Archives	Каталог для хранения архивов с версиями фалов проекта. Внутри этого каталога создается структура подкаталогов, соответствующих включенным в описание проекта.
<Dir> History	Каталог для хранения истории изменений в хранилище версий.
<Dir> Locks	Каталог для хранения файлов блокировки, создаваемых TeamSource при выполнении процедур Check-In, Pull и т.п.
logs.txt	Журнал работы TeamSource с данным проектом.
summary.txt	Сводные данные по каждому сеансу работы TeamSource с данным проектом.

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

В TeamSource блокировка всего проекта или отдельных его составляющих производится только на время выполнения различных глобальных операций, таких, как процедура Check-In, создание "зеркала" хранилища (mirroring), изменение глобальных параметров проекта TeamSource и некоторых других. В остальных случаях блокировки проекта или отдельных его составляющих не производится.

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

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

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

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

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

В TeamSource подсистема оповещения тесно интегрирована с функционалом самого контроллера версий, что в значительной степени снижает проблемы с ее настройкой и эксплуатацией. Передача сообщений об изменениях в проекте осуществляется по протоколу SMTP (Simple Mail Transfer Protocol), являющемуся стандартом для Intranet/Internet и поддерживаемому всеми без исключения программами почтовых серверов, что позволяет легко интегрировать оповещение TeamSource в общую инфраструктуру электронных почтовых рассылок компании.

Разрешение конфликтов

С точки зрения участника проекта TeamSource поддерживает две копии файлов проекта: локальную и удаленную. Локальная копия находится в полной и безраздельной власти разработчика, тогда как удаленная копия (хранилище версий) накладывает на его действия ограничения, заданные администратором проекта (root user). Таким образом, даже если участник проекта, не имеющий права на модификацию той или иной его составляющей все же внесет изменения в такой модуль, во время процедуры Check-In TeamSource не позволит этим изменениям попасть в хранилище версий. В случае же наличия возможности более чем у одного разработчика модифицировать одну и ту же составляющую проекта и возникновении конфликта версий (дата и время модификации вносимой версии старше чем у ранее внесенной и т.п.), TeamSource выдаст соответствующее предупреждение и перейдет в режим интерактивного разрешения конфликта, в котором у пользователя имеется возможность просматривать конфликтный модуль проекта в режиме сравнения, когда внесенные изменения по отношению к предыдущей версии специальным образом помечаются.

Рисунок 2. Окно TeamSource в режиме сравнения исходного кода двух версий.

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

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

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

Основные этапы работы с TeamSource

Поскольку TeamSource является достаточно небольшим по объему и простым в установке продуктом, не буду уделять много внимания процессу его инсталляции. Следует отметить лишь два момента:

· Если Вы устанавливаете TeamSource с дистрибутивного компакт-диска Delphi Client/Server, в состав которого входит TeamSource, рекомендуется запускать инсталляцию из программы-заставки компакт-диска, поскольку в данном случае Вам не потребуется вводить серийный номер и ключ авторизации.

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

Первичная настройка TeamSource

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

Рисунок 3. Приглашение мастера первичной настройки TeamSource.

Далее следует диалог, в котором вводится полное имя пользователя (используется в подсистеме оповещения и внутри проектов TeamSource), а также адрес e-mail пользователя:

Рисунок 4. Страница мастера первичной информации для ввода идентификационных данных пользователя.

Обратите внимание, что имя пользователя (User Name) является фиксированным значением. Оно получается из настроек рабочей станции и служит для идентификации пользователя в сети и при работе с хранилищем версий.

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

Диалог "Preferences" состоит из двух закладок. На первой задаются общие параметры, используемые при работе TeamSource: имя пользователя и адрес e-mail, а также три необязательных режима:

· "Update local file on each checkin (get after put)": повторное получение локальных копий файлов сразу после их передачи в хранилище версий. Может быть использован в том случае, если контроллер версий осуществляет автоматическую модификацию исходного текста при выполнении операции Check-In, например проставляет дату и время выполнения Check-In, версию или другую информацию.

· "Ignore spaces in files during compares": игнорировать ведущие и концевые пробелы в строках при сравнении текстовых файлов. Таким образом можно избежать выделения подобных строк как измененных в окне сравнения версий.

· "Automatically import comments during reconcile": автоматически импортировать комментарии из окна "Recommended changes" при выполнении операции Check-In. Если этот режим выключен, Вы всегда можете произвести импорт комментариев из контекстного меню "Recommended changes" удаленного (Remote) проекта (хранилища версий).

Рисунок 5. Диалог настроек TeamSource. Задание общих параметров.

На закладке "File Viewers" диалога "Preferences" задаются связи между расширениями имен файлов и средствами просмотра. Изначально внутреннее средство просмотра связано с расширениями .c, .cpp, .dfm, .hpp, .pas, .rc и .txt. Вы можете добавить в этот список любое из необходимых Вам расширений, однако при этом следует помнить, что внутреннее средство просмотра TeamSource предназначено для работы с текстовыми (ASCII) файлами. Если же файл того типа, для которого Вы создаете связь, является картинкой или другим бинарным форматом, то его расширение следует поместить в окно внешних средств просмотра. Файлы с расширениями, перечисленными в этом окне, просматриваются при помощи стандартного связывания расширений имен файлов со средствами просмотра Windows, прописанного в Registry.

Рисунок 6. Диалог настроек TeamSource. Задание типов средств просмотра для различных расширений имен файлов.

Теперь, когда мы рассмотрели этапы настройки общих параметров TeamSource, перейдем к созданию нового проекта TeamSource.

Создание нового проекта TeamSource

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

Рисунок 7. Выбор режима для создания нового проекта.

При импорте проекта выводится стандартный диалог выбора файла, а затем TeamSource переходит к стандартному интерфейсу в режиме Info. При создании же нового проекта запускается специальный мастер:

Рисунок 8. Мастер создания нового проекта. Ввод имени проекта и имени файла для сохранения его параметров.

На данном шаге задается имя проекта как оно будет затем отображаться во всех дальнейших операциях (Внимание: в дальнейшем имя проекта можно будет изменить только прямым редактированием файла проекта, поскольку в интерфейсе эта возможность заблокирована). Имя файла проекта (без информации о каталоге) формируется автоматически из имени проекта путем удаления пробелов, однако может быть введено и вручную. Контроллер версий выбирается из списка, в котором отображаются все активные контроллеры, подключенные на данный момент к TeamSource.

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

Рисунок 9. Мастер создания нового проекта. Ввод имени корневого каталога проекта.

Обратите внимание, что имя каталога может быть задано как в формате UNC с указанием хост-машины (то есть каталог может располагаться на удаленной станции), так и в обычном формате, с указанием полного пути.

Предположим, что мы решили разместить хранилище на диске H: компьютера с именем NIKITA в каталоге TeamSource\DemoProject. Тогда базовый каталог полностью будет выглядеть так: \\NIKITA\H:\TeamSource\DemoProject.

Следующим шагом является определение каталогов для хранилища версий (Archives), файлов истории (History) и блокировок (Locks). При использовании указанного нами ранее пути этот диалог мастера будет иметь следующий вид:

Рисунок 10. Мастер создания нового проекта. Ввод имен каталогов хранилища версий проекта.

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

Следующим шагом мастера является включение режима автоматического создания резервной копии хранилища версий:

Рисунок 11. Мастер создания нового проекта. Задание параметров резервного копирования.

В данном диалоге вводится путь к корневому каталогу, в котором будет создаваться резервная копия ("зеркало") хранилища версий. Этот параметр может быть изменен в дальнейшем через меню Project | Options.

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

Следующим шагом является задание имен файлов истории и журнала, а также имени SMTP-сервера, который будет использоваться для рассылки сообщений подсистемой оповещения. Эти параметры могут быть затем изменены через меню Project | Options.

Рисунок 12. Мастер создания нового проекта. Задание имен файлов истории, журнала и имени SMTP-сервера для рассылки сообщений подсистемой оповещения.

В том случае, если Вы задали имя SMPT-сервера, мастер перейдет к диалогу ввода адресов e-mail для рассылки. Если имя SMTP-сервера введено не был, осуществляется переход к последней странице мастера.

Рисунок 13. Мастер создания нового проекта. Ввод адресов e-mail для рассылки оповещений.

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

Рисунок 14. Мастер создания нового проекта. Страница со сводной информацией о созданном проекте.

Последняя страница мастера содержит сводную информацию о проекте. После нажатия кнопки "Finish" TeamSource переходит к вводу данных о локальных каталогах проекта. Это может быть сделано при помощи специального мастера (Content Wizard) и диалога для ввода локальных каталогов проекта. Content Wizard может быть запущен для работы с любым из локальных каталогов проекта и помогает в определении файловых фильтров и деревьев подкаталогов. Предположим, наш программный проект расположен в каталоге E:\DE5\TeamSource Demo Project и имеет один вложенный каталог SubFolder. Тогда Content Wizard будет иметь следующий вид:

Рисунок 15. Content Wizard — средство для ввода параметров обработки локальных каталогов программного проекта.

Как мы видим, Content Wizard позволяет редактировать список файловых масок инклюзивного фильтра (то есть фильтра, определяющего, какие из файлов ДОЛЖНЫ обрабатываться контроллером версий) для каждого из локальных каталогов. Также имеется возможность полностью удалить какой-либо из подкаталогов, кроме самого верхнего, включенного непосредственно в проект TeamSource (кнопка Delete Directory).

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

Рисунок 16. Подтверждение создания недостающего подкаталога в хранилище версий.

В данном случае TeamSource обнаружил подкаталог SubFolder в локальном каталоге нашего проекта и предложил создать его аналог в хранилище версий.

Далее TeamSource переходит в режим Local. Этот режим отображения описывается в разделе "Работа с локальной копией проекта (Local)".

Открытие существующего проекта

Открытие существующего проекта TeamSource производится через специальный диалог, появляющийся при запуске TeamSource или при выборе пункта меню File | Open Project:

Рисунок 17. Диалог выбора проекта TeamSource.

Далее TeamSource переходит в режим Local (раздел "Работа с локальной копией проекта (Local)") если для проекта уже заданы локальные каталоги, или же в режим Content Wizard.

Изменение параметров существующего проекта

Для изменения параметров существующего проекта следует воспользоваться меню Project. Обратите внимание, что некоторые из пунктов данного меню могут быть заблокированы при переходе к ним в режиме Local или Remote. Это связано с тем, что для выполнения некоторых операций, влекущих за собой изменение глобальных параметров хранилища версий и (или) локальной копии проекта требуется наличие блокировки (lock) проекта. Блокировка необходима для изменения любого из параметров, связанных с хранилищем версий (каталоги размещения хранилища, режим "зеркалирования" и так далее). Выполнение операции блокировки описывается в разделе "Операции, возможные как в режиме Local, так и Remote

Среди таких операций следует выделить следующие:

блокировка проекта от изменений
создание закладок (bookmarks)
операция Pull (Check-Out)

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

Рисунок 18. Изменение имени файла проекта, сопоставленного записи в реестре проектов.

Параметрами проекта, непосредственно связанными с контролем версий, можно управлять через диалог “Project Options”, открывающемуся через меню Project | Options.

Примечание: Для изменения большинства значений в этом диалоге необходимо наличие блокировки удаленной копии проекта (хранилища версий). Смотри раздел "Операции, возможные как в режиме Local, так и Remote

Среди таких операций следует выделить следующие:

блокировка проекта от изменений
создание закладок (bookmarks)
операция Pull (Check-Out)

Блокировка проекта".

Рассмотрим более подробно назначение параметров, отображаемых в этом диалоге.

Рисунок 19. Изменение параметров проекта. Закладка "General": общие параметры.

Таблица 2. Назначение параметров проекта на закладке "General" диалога 'Project Options"

Название параметра	Назначение
Version info file name	Имя файла версий. В данном файле содержится информация о номере версии проекта. Создается автоматически при выполнении операции Pull в корневом каталоге локального проекта.
Detect new local directories	Определять наличие созданных заново локальных каталогов. При включении этой опции TeamSource будет автоматически предлагать запуск мастера Content Wizard для обнаруженных каталогов.
Require summary comments	Требовать ввод общих комментариев при выполнении Check-In.
Require file comments	Требовать ввод комментариев для каждого файла при выполнении операции Check-In. Примечание: рекомендуется включать эту опцию только после выполнения первой операции Check-In для проекта, в состав которого изначально входит большое число файлов. В этом случае комментарии можно будет проставить позже, в то же время упростив операцию первичного наполнения хранилища версий.
Build numbers	Начальный номер версии проекта.

Рисунок 20. Изменение параметров проекта. Закладка "Directories": каталоги хранилища версий проекта и резервной копии хранилища.

Таблица 3. Назначение параметров проекта на закладке "Directories" диалога 'Project Options"

Название параметра	Назначение
Archives directory	Каталог для размещения файлов хранилища версий*
History directory	Каталог для размещения файлов истории*
Lock file directory	Каталог для размещения файлов блокировки*
Enable mirror directory	Включить режим создания "зеркальной" копии хранилища версий.
Mirror directory	Корневой каталог для создания "зеркальной" копии хранилища версий. Примечание: при включенной опции "Enable mirror directory" и в случае недоступности этого каталога на момент открытия проекта TeamSource будет выдано сообщение об ошибке и проект открыт не будет.
Mark Mirror files as Read-Only	Помечать файлы в "зеркальной" копии атрибутом "только чтение".

* В многопользовательском режиме работы каталог должен быть доступен для всех участников проекта.

Рисунок 21. Изменение параметров проекта. Закладка "Users": список пользователей.

В закладке "Users" дается возможность создания пользовательских бюджетов для участников проекта. Пользователю можно присвоить идентификатор (user name), пароль (password) и права доступа (access rights), а также признак администратора проекта. Пользователь с признаком "администратор" обладает возможностью создавать не ограниченные по времени блокировки проекта, создавать бюджеты других пользователей и выполнять некоторые другие действия, недоступные пользователям, не имеющим такого признака. Эти параметры задаются в диалоге нижнего уровня "User Information":

Рисунок 22. Изменение параметров проекта. Диалог задания прав доступа пользователя к проекту.

Рисунок 23. Изменение параметров проекта. Закладка "Publishing": параметры подсистемы оповещения.

В закладку "Publishing" включены параметры подсистемы оповещения.

Таблица 4. Назначение параметров проекта на закладке "Publishing" диалога 'Project Options"

Название параметра	Назначение
SMTP server	Адрес (в формате URL) SMTP-сервера для рассылки сообщений
Publish summaries to	Список адресов e-mail для рассылки сводных отчетов об операциях с хранилищем версий
Master summary file	Полное имя файла для хранения сводных отчетов (смотри также раздел "Создание нового проекта TeamSource")
Publish logs to	Список адресов e-mail для рассылки журналов операций с хранилищем версий
Master log file	Полное имя файла главного журнала (смотри также раздел "Создание нового проекта TeamSource")
Publish file changes to	Список адресов e-mail для рассылки детальных отчетов об изменениях в отдельных файлах при выполнении операций Check-In.

Перечисленные выше параметры, управление которыми осуществляется через диалог "Project Options", определяют основные режимы работы TeamSource, общие для всех режимов (History, Local, Remote, Info).

Параметры текущего контроллера версий проекта

Еще одна группа общих для всего проекта параметров задается в диалоге "Controller Options". В этом диалоге Вы можете просмотреть и (при наличии такой возможности) отредактировать отдельные значения параметров контроллера версий, назначенного для текущего проекта.

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

Рисунок 24. Диалог задания параметров контроллера версий.

Удаление проекта

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

Замечание: проект не должен быть открыт в TeamSource.

После подтверждения проект будет удален из реестра.

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

Работа с локальной копией проекта (Local)

В этом режиме TeamSource автоматически проверяет совпадение версий файлов в локальном каталоге с хранилищем версий и предоставляет информацию о найденных изменениях в двух полях отображения: "Recommended changes to your Local project" и "Recommended changes to the Remote project" (смотри "Рисунок 25. TeamSource в режиме работы с локальной копией проекта.").

Окно TeamSource в режиме Local также содержит выпадающий список "Local Directory" в левом верхнем углу. Этот список содержит все локальные каталоги, включенные в проект и предназначенные для проверки на появление изменений. Для того, чтобы просмотреть изменения в каждом отдельно взятом каталоге, Вам необходимо выбрать этот каталог из списка. Отображение в левом и правом полях окна Local автоматически изменится, придя в соответствие с состоянием выбранного каталога.

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

При выборе корневого каталога проекта или одного из списка каталогов, окно TeamSource принимает следующий вид:

Рисунок 25. TeamSource в режиме работы с локальной копией проекта.

Ситуация на рисунке расшифровывается следующим образом:

· В локальном проекте найдены два новых файла (AnotherForm.dfm и AnotherForm.pas), которых еще нет в хранилище версий. Рекомендуемая операция: внести файлы в хранилище (Check In).

· В файлах Main.dfm и Main.pas произошли изменения, не конфликтующие с текущей версией. Рекомендуемая операция: внести файлы в хранилище (Check In).

· Файл Text File To Be Deleted.txt, ранее внесенный в хранилище версий, был удален из локального проекта. Рекомендуемая операция: удаление файла из хранилища (Remove).

· Дата и время файлов SubForm.dfm, TeamSourceDemoProject.cfg и TeamSourceDemoProject.res изменились по сравнению с последней версией в хранилище, однако размер и контрольная сумма остались прежними. Рекомендуемая операция: привести дату и время в соответствие с версией в хранилище (Touch).

· Файл SubForm.pas изменился, однако его дата и время старше, чем у версии, находящейся в хранилище (конфликт версий). TeamSource не имеет возможности разрешить конфликт автоматически. Рекомендуемая операция: исправить файл вручную (Correct by hand).

Если мы выделим один или более файлов в левом или правом списке, то кнопка "Do It" перейдет в активное состояние и при нажатии на нее будут выполнены соответствующие, рекомендованные TeamSource, операции. Если Вам необходимо сменить тип рекомендуемой операции, необходимо щелкнуть правой кнопкой мыши на соответствующем файле. Появится всплывающее меню:

	Первый пункт меню (здесь: Get Help)	Выполнение рекомендуемой операции.
	View Local Changes	Просмотр изменений в локальной копии относительно последней копии в хранилище версий
	View Remote Changes	Просмотр изменений в одной версии в хранилище относительно другой
	View All Changes	Просмотр всех изменений (локальных и удаленных)
	View File Info	Просмотр информации о файле: дата и время локальной копии, дата и время копии в хранилище, последняя версия файла в хранилище.
	Change File Status	Изменение рекомендуемого действия для файла.

Рисунок 26. Всплывающее меню списка файлов и действий для локальной копии проекта.

	Первый пункт меню (здесь: Check In)	Выполнение рекомендуемой операции.
	View Local Changes	Просмотр изменений в локальной копии относительно последней копии в хранилище версий
	View Remote Changes	Просмотр изменений в одной версии в хранилище относительно другой
	View All Changes	Просмотр всех изменений (локальных и удаленных)
	View File Info	Просмотр информации о файле: дата и время локальной копии, дата и время копии в хранилище, последняя версия файла в хранилище.
	Ignore (move to other pane)	Игнорировать и переместить в другой список.
	Revert	Принудительно записать файл поверх предыдущих версий без учета конфликтов и других факторов.
	Edit File Comment	Редактирование комментария к файлу в хранилище версий.
	Import Comments	Импорт комментариев из предыдущих версий файла в новую.

Рисунок 27. Всплывающее меню списка файлов и действий для удаленной копии проекта.

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

Рисунок 28. Сравнение изменений в версиях файла.

Здесь желтым цветом и знаком "+" отмечены строки, добавившиеся в файл, а красным цветом и знаком "-" — строки, удаленные из файла. В нижнем окне отображается комментарий к той версии (локальной или удаленной), которая сравнивается с версией из хранилища. В заголовке окна отображаются номера и состояния сравниваемых версий.

Работа с хранилищем версий (Remote)

В режиме Remote TeamSource переходит к отображению текущего состояния хранилища версий (или удаленной копии проекта). Аналогично режиму Local окно режима Remote разбито на две части. В левом поле представлен список каталогов хранилища версий, причем корневой каталог помечен как root. При перемещении курсора (выделения) по дереву каталогов правое поле окна Remote синхронно отображает список файлов и всех их версий, причем при нажатии на панель заголовка соответствующего столбца можно отсортировать этот список по соответствующему полю.

Рисунок 29. TeamSource в режиме работы с хранилищем версий проекта.

В левой верхней части окна также имеется список "Local Directory", а в правой — индикатор режима работы с хранилищем версий. Он принимает состояния "Read only" и "Read/Write" в зависимости от отсутствия или наличия блокировки проекта пользователем TeamSource (см. раздел "Блокировка проекта" на странице 28).

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

	Add…	Добавить каталог в хранилище версий
	Delete	Удалить каталог из хранилища версий
	Properties…	Свойства каталога хранилища версий

Рисунок 30. Контекстное меню окна каталогов удаленной копии проекта (хранилища версий).

При выборе пункта Add… выполняется процедура задания имени каталога, который создается в хранилище версий, а при выполнении операции Pull будет создан и в локальной копии.

При выборе пункта Delete каталог хранилища версий будет удален со всем его содержимым. При выполнении этого действия TeamSource запрашивает подтверждение на удаление каталога.

Выбор Properties… открывает диалоговое окно "Directory Properties", в котором можно изменить те или иные параметры каталога хранилища версий и режим обработки соответствующего локального каталога.

Рисунок 31. Диалог ввода глобальных параметров каталога проекта TeamSource.

Таблица 5. Назначение полей диалога "Directory Properties"

Название параметра	Назначение
Version controller	Только для чтения. Строка-идентификатор контроллера версий, назначенного для данного каталога.
Includes	Список файловых масок инклюзивного фильтра для выполнения операций Check-In. Отдельные маски разделяются между собой символом "точка с запятой".
Excludes	Список файловых масок эксклюзивного фильтра для выполнения операций Check-In. Отдельные маски разделяются между собой символом "точка с запятой".
Productions	Перечень пар файловых расширений, указывающих, какие файлы в проекте генерируются автоматически и из каких с целью исключить "опознание" сгенерированных файлов при операции Check-In как новых или изменившихся.

Параметр Productions заполняется при помощи специального диалога, вызываемого по кнопке "Define…".

Рисунок 32. Определение расширений файлов, создаваемых динамически и не включаемых в хранилище версий.

В этом диалоге задаются соответствия между расширениями имен файлов, показывающие, что файлы с расширением в столбце "Target" автоматически генерируются из файлов с расширениями в столбце "Source". Это позволяет избежать включения в список новых и измененных файлов при выполнении операции Check-In автоматически создаваемых файлов.

В правом поле окна Remote отображается список файлов и их версий. Для этого поля (списка) контекстное меню имеет следующий вид:

	View Tip Revision	Просмотр текущей версии выделенных файлов
	View Any Revision	Просмотр версии по выбору
	Save Revision As…	Сохранить выделенную версию поверх выбираемой из списка версии
	Remove from project…	Удалить версию из проекта
	View Archive Report	Просмотр отчета о состоянии архива версий
	Compare Revisions…	Сравнение двух произвольных версий выделенного файла
	Set Revision Number	Установка для выделенного файла произвольного номера версии, выбираемой из списка
	Fix Tip Revisions…	Запуск процесса проверки соответствия указателей на текущую версию файла.

Рисунок 33. Контекстное меню окна версий файлов в хранилище версий.

Просмотр версий файла (произвольная версия, текущая версия)

В режиме просмотра произвольной или текущей версии файла TeamSource открывает окно, аналогичное представленному на Рисунок 28. При просмотре произвольной версии выбор версии для просмотра осуществляется при помощи следующего диалога:

Рисунок 34. Диалог выбора версии файла.

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

Сохранение одной версии поверх другой

При выборе этой операции TeamSource предлагает выбрать из списка (Рисунок 34) номер версии, поверх которой будет сохранена выделенная в правом поле окна Remote версия.

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

Удаление версии из проекта

При выполнении этой операции все версии файлов, выделенные в правом поле окна Remote, будут удалены из хранилища версий. Перед удалением выделенных версий TeamSource выводит соответствующее предупреждение.

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

Просмотр информации об архиве версий

При выполнении этой операции TeamSource открывает окно с отчетом о состоянии архива, в котором хранится выделенная версия файла с полным перечнем всех версий, размера архива и так далее.

Рисунок 35. Отчет о состоянии архива версий.

Сравнение двух версий файла

При выполнении сравнения версий файла TeamSource сначала выводит диалог выбора версий для просмотра (см. Рисунок 36. Диалог выбора версий для сравнения.), а затем открывает стандартное окно сравнения файлов (см. Рисунок 2).

Рисунок 36. Диалог выбора версий для сравнения.

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

Назначение номера версии

Эта операция предназначена для переназначения номера версии выделенной в правом поле окна Remote версии того или иного файла. При выполнении этой операции TeamSource открывает диалог выбора версии (Рисунок 34) для назначения взамен текущей. При попытке назначить версии файла того же самого признака версии TeamSource не производит никаких действий.

Проверка и актуальности указателей текущих версий

Этот режим прежде всего предназначен для администраторов проектов. При выполнении проверки актуальности указателей текущих версий TeamSource проверяет каждый из выделенных файлов на совпадение указателя на его текущую версию со списком версий. В том случае, если TeamSource обнаруживает несоответствие, выдается диалог (Рисунок 34), позволяющий скорректировать указатель текущей версии.

Операции, возможные как в режиме Local, так и Remote

Среди таких операций следует выделить следующие:

блокировка проекта от изменений
создание закладок (bookmarks)
операция Pull (Check-Out)

Блокировка проекта

Блокировка проекта может быть выполнена либо пользователем, обладающим соответствующими правами доступа к проекту, либо администратором проекта. Последний обладает возможностью создать блокировку, не имеющую ограничения по времени (см. Рисунок 38).

Для выполнения блокировки проекта следует вызвать контекстное меню окна "Lock List".

Рисунок 37. Контекстное меню окна блокировок. Запрос на создание блокировки проекта.

При выборе пункта "Request Lock" TeamSource открывает диалоговое окно, в котором задаются параметры блокировки, используемые, в основном, при отображении ее в списке блокировок проекта, что весьма важно при работе в многопользовательском режиме (параметр "Lock Comment").

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

При установке признака "Lock as Administrator" в списке блокировок TeamSource отображается соответствующее примечание в столбце "Lock Time".

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

Рисунок 38. Диалог параметров блокировки.

Когда блокировка создана, TeamSource активизирует соответствующие пункты контекстного меню, позволяющие:

снять блокировку (Clear Lock);
изменить комментарий блокировки (Edit Lock Comment);
продлить время действия блокировки (Extend lock…);
передать блокировку другому пользователю, выбрав его из списка (Yield to…);
проверить состояние блокировки проекта другим пользователем (Verify Current Lock).

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

Рисунок 39. Окно списка блокировок и контекстное меню с активированными пунктами управления блокировками.

Примечание: При проверке блокировки (Verify Current Lock) TeamSource действует следующим образом:

Если время, установленное при создании блокировки, еще не истекло, владелец блокировки никак не оповещается и TeamSource не выполняет никаких действий, кроме выдачи соответствующего сообщения пользователю, выполнившему проверку.
Если время вышло, то пользователю, создавшему "устаревшую" блокировку, выдается предупреждение с обратным отсчетом в две минуты. За это он должен либо продлить блокировку (Extend Lock), либо передать ее пользователю, выполнившему проверку. Если в течении двух минут никаких из перечисленных действий выполнено не было (например пользователь создал блокировку и надолго отлучился с рабочего места), блокировка автоматически снимается.

Создание и использование закладок (bookmarks)

Закладки предназначены для пометки текущей версии (см. раздел "Версии проекта и отдельных его составляющих" на странице 6) проекта таким образом, чтобы затем использовать эту пометку для выполнения например процедуры Pull.

Поскольку при установке закладки помечаются все файлы, входящие в проект, Вы можете установить закладку после выполнения операции Check-In для окончательных версий файлов для какого-либо ключевого состояния проекта (например для бета-версии). Удостоверившись, что все файлы текущей версии могут быть использованы для сборки проекта, Вы устанавливаете закладку с соответствующим комментарием. За счет этого даже при внесении последующих изменений Вы будете обладать возможностью собрать версию проекта, составляющие которой помечены закладкой. Для этого необходимо сначала выполнить операцию Pull в отдельный каталог, выбрав предварительно необходимую закладку из списка, выводимого TeamSource (Рисунок 42), а затем выполнить сборку проекта, используя исходные тексты из соответствующего каталога.

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

Для управления закладками в TeamSource используется специальный диалог, открывающийся через меню Project | Bookmarks... .

Рисунок 40. Диалог управления закладками в проекте.

При создании закладки (кнопка "Add") выводится диалог "Bookmark Properties".

Рисунок 41. Диалог создания закладки.

Закладка может быть локальной (Local) или глобальной (Global). Глобальные закладки будут видны и могут быть использованы всеми участниками проекта, тогда как локальные видны и используются только создавшим их пользователем. Создавать глобальные закладки имеют право только пользователи с признаком Administrator (см. "Изменение параметров существующего проекта" на странице 17).

Операция Pull (Check-Out)

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

Рисунок 42. Диалог выбора закладки для выполнения операции Pull.

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

В том случае, если в списке Bookmark выбран первый пункт (None (current state)), TeamSource создаст локальную копию последних версий файлов проекта.

Операция Pull выполняется начиная с корневого каталога, указанного в поле "Local directory" в верхней части окна Remote.

Работа с историей версий проекта (History)

При переходе в режим History интерфейс TeamSource принимает следующий вид:

Рисунок 43. TeamSource в режиме "History".

В этом режиме Вы имеете возможность просматривать все изменения в проекте, сделанные с момента его создания. В левом поле окна History отображается список операций с хранилищем версий с указанием даты, времени и имени пользователя, выполнившего операцию. Справа отображается соответствующий файл истории (см. раздел "Хранилище TeamSource" на странице 6), в котором перечислены изменения в проекте и другие данные о производившихся операциях. Вы имеете возможность выгрузить файл историю помеченной операции в локальный текстовый файл, воспользовавшись контекстным меню левого поля окна History.

Подсистема оповещения об изменениях в проекте

Подсистема оповещения или Publishing System продукта TeamSource тесно интегрирована с другими частями хост-приложения. За счет сведения к разумному минимуму настроек этой подсистемы становится возможным быстро и без особых проблем настроить оповещение участников проекта об изменениях в хранилище версий.

К тому же, за счет использования для рассылки протокола SMTP (Simple Mail Transfer Protocol) Вы можете использовать для оповещения стандартный внутрифирменный сервер сообщений (практически все современные операционные системы серверного класса поддерживают этот протокол и соответствующие службы) и даже использовать почтовый сервер вашего Internet-провайдера для рассылки оповещений разработчикам, работающим вне офиса, в другом городе и даже на другой стороне земного шара.

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

Так, пользователи из списка "Publish Summaries To:" будут получать только сводные отчеты об операциях с хранилищем версий, не содержащие технической информации, а только с комментариями к операции Check-In, именем пользователя, выполнявшего операцию и датой ее проведения.

Пользователи из списка "Publish Logs To:" будут получать журналы выполнения операций Check-In и других действий со всей технической информацией.

Пользователи из списка "Publish File Changes To:" будут получать сводные отчеты, содержащие информацию о том, какие файлы были добавлены или удалены из проекта.

Рисунок 44. Настройка подсистемы оповещения.

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

Несколько практических советов

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

Как не следует настраивать и эксплуатировать TeamSource.

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

b) Не оставляйте включенным флаг "Enable Mirror Directory" (см. раздел "Изменение параметров существующего проекта" на странице 17) перед закрытием проекта в том случае, если имеется вероятность того, что путь, указанный в параметре "Mirror Directory" может оказаться недоступным, например, если Вы создали этот каталог на съемном носителе и извлекли его из привода. При открытии проекта и недоступности этого пути TeamSource выдаст сообщение об ошибке и не откроет проект до тех пор, пока путь не будет создан заново или устройство не будет приведено в готовность.

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

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

e) Не пренебрегайте читаемостью названий имен проектов, комментариев к блокировкам и т.п. Зачастую неверно истолкованное название или комментарий может создать больше проблем, чем полный "обвал" компьютерной сети или сбой жесткого диска с хранилищем версий проекта.

f) Не раздавайте всем участникам проекта признак Administrator – ничего кроме проблем с блокировками это не принесет.

g) При создании проекта TeamSource по программному проекту, достаточно давно находящемуся в разработке, не включайте признак "Require File Comments" (Рисунок 19. Изменение параметров проекта. Закладка "General": общие параметры.) при первичном наполнении хранилища версий. Если в проекте уже имеется не одна сотня файлов, даже нажать на кнопку "OK" сотню-другую раз во время выполнения цикла Check-In будет достаточно утомительно. Комментарии можно будет ввести позже прямо в хранилище версий.

Как следует настраивать и эксплуатировать TeamSource.

a) Выделите для хранилища версий отдельный дисковый раздел на доступной через компьютерную сеть машине. Лучше если это будет выделенный файловый сервер, например на базе Novell Netware с включенной поддержкой длинных имен или Windows NT с дисками, отформатированными в NTFS. Создайте отдельные каталоги для разных рабочих групп, а уже в них создавайте хранилища версий. На такую структуру легко наложить права доступа для отдельных пользователей, например защитить от стирания корневые каталоги хранилищ версий.

b) Производите циклическое резервное копирование хранилища версий либо его "зеркальной" копии на специальное устройство массового хранения (стример, магнитооптику, CD-RW и т.п.) не менее чем раз в сутки.

c) Поскольку архивы версий имеют тенденцию со временем разрастаться, после очередного резервного копирования, например раз в месяц, имеет смысл удалять ненужные версии файлов из архивов.

d) Расставляйте закладки на все значимые версии проекта, снабжая их содержательными комментариями. Впоследствии это может сэкономить массу времени при отладке или поиске необходимой версии.

e) Включите признак "Require File Comments" (Рисунок 19. Изменение параметров проекта. Закладка "General": общие параметры.) после первичного наполнения хранилища версий или при создании проекта TeamSource параллельно новому программному проекту. Одна-две фразы содержательного комментария для одного-двух файлов за операцию Check-In с одной стороны не займут много времени разработчика, а с другой стороны — помогут ему же разобраться с тем, что именно было изменено или добавлено в -1871 версии файла по исчислению проекта и два-три года назад по реальному времени.

f) Включайте в проекты TeamSource помимо собственно файлов проекта и файлы документации по этому проекту, например сопроводительную документацию к версиям продукта. Это опять-таки поможет сэкономить время при сборке конечной версии.

g) И наконец, ВНИМАТЕЛЬНО читайте сообщения TeamSource, особенно при выполнении различных необратимых действий на фоне длительного отсутствия резервного копирования хранилища версий (см. также пункт b).

Заключение

Итак, мы рассмотрели устройство и приемы работы системы контроля (управления) версий программных проектов TeamSource. За простым, незамысловатым интерфейсом этого программного продукта скрывается совсем не простое внутренне устройство, созданное разработчиками для разработчиков и потому достаточно действенное, чтобы покрыть 90 (если не более) процентов потребностей большинства как одиночных разработчиков программного обеспечения, так и групп программистов. Поэтому не следует смущаться отсутствием различных красивостей и непомерных объемов исполняемых файлов, ведь все гениальное — просто!

К тому же, Вы имеете прекрасную возможность внести собственный вклад в развитие этого перспективного продукта, так необходимого пользователям средств разработки Inprise/Borland (и не только!). Берите на вооружение API расширений TeamSource и Borland Delphi (или C++ Builder) и создавайте свои собственные, сложные (или простые) средства, облегчающие вашу работу.

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