Средства автоматизации коллективной разработки программных проектов.

Предварительный (№24) вариант.

 

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

 

Введение

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

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

Единственный выход – разрешить каждому программисту модифицировать код в той части проекта, которая является объектом его работы. При этом, правда, возникает проблема синхронизации изменений, внесенных одновременно разными людьми в один и тот же файл. Конечно, каждый может вручную помещать в проект измененные им файлы, стараясь при этом не уничтожить изменения своих коллег (что удается не всегда), однако на это уходит значительное количество времени. Таким образом, возникает потребность в ПО контроля и объединения версий.

Во время разработки любого проекта необходимым действием является регулярное сохранение предыдущих версий файлов (backup) с возможностью быстрого их восстановления. Необходимость в этом возникает, в частности, при поиске причины появления новых ошибок между версиями (bug tracking). Самым простым решением является использование для этих целей мощного архиватора, стримера и т.п., но их работа при больших размерах проекта может растянуться на часы. Более того, часто желательно сохранять каждую версию каждого файла, снабжая ее для избежания путаницы комментарием: кто изменил этот файл и зачем. Для этих целей используются системы контроля версий (Version Control Systems).

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

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

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

a)    один человек раздает задания всем программистам, а затем сам объединяет результаты их труда;

b)    все происходит, как в случае a), только за объединение разработок отвечает сразу несколько человек;

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

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

В этой статье обсуждаются в основном средства автоматизации объединения и контроля версий для случаев c) и d), характерных для достаточно больших и долгосрочных проектов. Также рассматривается возможность использования этих средств для случаев a) и b), обычных при разработке ПО более мелких масштабов и для ситуаций, когда передача информации затруднена (например, люди в основном работают дома и приносят на работу результаты своего труда на дискетах).

 

Существующие решения

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

a)    доступ к этой базе данных,

b)    подстройка символов перевода строки в текстовых файлах (CR,LF или просто LF) под ту операционную систему, которую использует данный разработчик,

c)    обработка конфликтующих версий (возникающих при изменении разными программистами одновременно одного и того же файла),

d)    именование различных версий и

e)    ввод комментариев к изменениям.

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

Стоит отметить, что некоторые СКР, построенные на основе более примитивных систем контроля версий, используют их средства управления файлами. CVS, к примеру, при хранении своей базы данных использует RCS (Revision Control System), которая, в свою очередь, является обычной системой контроля версий.

 

Проект как объект коллективной работы

С точки зрения СКР, каждый проект представляет собой набор директорий и файлов различных типов, находящихся

a)    на компьютерах участников разрабатываемого проекта в выбранном ими месте (некоторые СКР, правда, не требуют локального хранения файлов, которые не находятся на редактировании у данного разработчика);

b)    в базе данных соответствующей программы объединения версий (обычно на сервере).

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

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

Итак, перед тем, как приступить к работе с проектом, нужно создать его базу данных – это делает администратор проекта. Затем все участники проекта получают, используя средства своей системы контроля версий, с сервера необходимые файлы на свой локальный диск по мере надобности – при этом обычно они могут получить любую из предыдущих версий, а также описание сделанных там изменений. Если данная СКР не основана на использовании центральной базы данных на сервере, то изначальный набор файлов проекта разработчики получают у администратора, а затем уже работают со своей локальной базой данных.

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

 

Рассматриваемые средства

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

1)    Concurrent Versions System (CVS). Работа этой программы основана на использовании командной строки. CVS имеет версии практически для всех диалектов UNIX, а также для DOS и Windows95/NT и фактически является стандартной СКР под UNIX. Будет также рассмотрена работа WinCVS - графического интерфейса для CVS, отчасти заменяющего работу в командной строке (имеет версии только под Windows 95/NT и MacOS). CVS распространяется свободно под лицензией GNU. Полную информацию можно получить по адресу www.cyclic.com.

2)    Microsoft Visual SourceSafe (VSS) 6.0. Работа с программой основана на использовании графического интерфейса, хотя часть действий пользователя можно производить и из командной строки. VSS 6.0 работает только под Windows 95/NT, хотя предыдущие (до приобретения прав на разработку этого продукта компанией Microsoft) версии работали также под MacOS и UNIX. VSS является коммерческим продуктом (msdn.microsoft.com/ssafe). Около $550 за копию.

3)    Code CO-OP (COOP) – система коллективной разработки бессерверного типа, ориентированная на обмен данными с использованием e-mail. Достаточно новая программа, работа с которой основана исключительно на использовании графического интерфейса. $150 за место (www.relisoft.com).

CVS и VSS основаны на использовании централизованной БД проекта, однако они достаточно сильно отличаются в деталях своего функционирования. Это объясняется тем, что структура VSS основана на неизбежном использовании графического интерфейса, а CVS изначально нацелена на использование командной строки. В основном эти два средства достаточно полно отражают возможности ПО своего класса.

Менее распространенные СКР, не требующие для своей работы постоянно работающего сервера, представлены в этой статье одной программой – Code Co-op, работа которой достаточно полно отражает специфику функционирования такого программного обеспечения. COOP не имеет многих полезных функций, касающихся работы с проектами, ветвления версий и т.п., однако о них будет достаточно подробно рассказано при описании CVS и VSS.

UNIX-версии, которые, как и у большинства остальных средств коллективной разработки (кроме появившихся совсем недавно, как Code Co-op) имеются у VSS и CVS, не будут явно упоминаться в этой статье. Их интерфейс командной строки такой же, как и в версиях для Windows, а графический интерфейс отсутствует. Тем не менее, из соображений безопасности рекомендую размещать базу данных проекта на UNIX-сервере.

Критерии сравнения рассматриваемых средств

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

-          способы хранения версий файлов в базе данных;

-          способы доставки новых версий файлов другим программистам;

-          способы обработки изменений, внесенных в один и тот же текстовый файл одновременно разными разработчиками;

-          способы работы с другими типами файлов;

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

-          наличие и реализация использования командной строки для тех же целей;

-          интегрируемость с другим ПО для разработчика, текстовыми редакторами, расширяемость;

-          контроль доступа к файлам проекта (security);

-          способы распространения данных средств (GNU, freeware, shareware или через торговую сеть) также во многих случаях весьма важны.

Принципы работы с СКР на примере этих средств

 

Хранение файлов в базе данных проекта

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

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

Практически все СКР хранят файлы в базе данных в виде последовательности изменений – от новой версии файла к старой, - а не каждую версию каждого файла целиком. Это значительно сокращает размер БД.

Если на одном из этапов разработки проекта из него удаляется какой-либо файл, соответствующая этому файлу запись в базе данных не удаляется (т.е. просто файл отмечается как удаленный начиная с данной версии). Стоит отметить, что многие СКР все же предоставляют специальную возможность удаления всей истории изменений какого-либо файла из своей БД, - исключительно с целью экономии места на диске. Однако при нормальных обстоятельствах необходимость использования такой функциональной "возможности" отсутствует.

 

Доступ к базе данных проекта

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

0)    Создание (инициализация) базы данных вашей системы контроля версий на сервере, если работа этой СКР основана на использовании сервера. В противном случае – создание соответствующего репозитория на машине каждого программиста.

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

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

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

4)    Получение разрешения на редактирование локальной копии файла, если это необходимо (обычно это действие связано со снятием предварительно установленного атрибута read only, или установкой разрешения на запись в файл под UNIX).

5)    Запуск редактора для этого файла, изменение, сохранение.

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

7)    Ввод автором изменений текстового комментария, кратко описывающего их смысл.

8)    После этого новая версия файла становится доступной другим программистам.

Различные системы коллективной разработки по-разному реализуют эту последовательность действий. Далее описаны подходы к этому процессу со стороны CVS, VSS и COOP.

 

Создание базы данных проекта на сервере и инициализация работы с ней

на машине участника проекта

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

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

Для Code Co-op, как и для всех остальных СКР бессерверного типа, необходимо создавать только локальную базу данных. Участник разработки, создающий новый проект, становится его администратором (это не является правилом для подобных COOP’у систем). Возможно как создание пустого проекта, так и импортирование уже имеющихся файлов в новый проект.

В принципе, в большинстве СКР, снабженных визуальным интерфейсом, файл из репозитория можно получить на редактирование в любую директорию. В CVS же, например, приходится вызывать команду cvs checkout, которая производит получение данного модуля (подпроекта) из базы данных, создание и инициализацию тех директорий на локальном диске, в которые он будет записан. Большинство команд CVS можно выполнить только в таким образом проинициализированных директориях. Дело в том, что для уменьшения количества параметров, набираемых разработчиком в командной строке при работе с этой СКР, CVS необходимо иметь достаточное количество информации о файлах, находящихся в пользовательской директории. Эти сведения CVS хранит в поддиректориях “CVS”, создаваемых как раз при первом получении модуля. В частности, там содержится список расположенных в соответствующей локальной директории файлов проекта с указанием их версий.

При работе с CVS в каждой пользовательской директории могут находиться файлы только из какой-то одной директории БД проекта. Это ограничение было введено, видимо, с целью повышения эффективности работы пользователей (чтобы они могли быстро получать файлы из репозитория, используя только их имена), хотя я не вижу тут никакого выигрыша. Путь к указанной директории репозитория и месторасположение самого репозитория также находятся в файлах из поддиректории “CVS”. Последнее дает программисту возможность безболезненно работать с несколькими различными репозиториями – в зависимости от его текущей локальной директории.

 

 

Работа с проектом после завершения всех настроек

Каждый программист может получить (check out) из базы данных любую версию одного или нескольких файлов (в т.ч. целиком весь проект), а также отправить (check in) в БД новые версии измененных им файлов.

Новая версия файла может быть добавлена в базу данных VSS только в случае, когда перед редактированием самая последняя версия этого файла была получена разработчиком из БД путем операции check out. Во время последней в базе данных VSS, в частности, отмечается, что данный файл редактируется данным программистом. Если для вызова на редактирование локальных копий файлов проекта не использовать графический интерфейс VSS или программ, в которые он интегрирован, то можно случайно отредактировать файл, который не был отмечен, как “checked out”. Изменения, сделанные в таком файле, не смогут попасть в БД проекта. Благодаря визуальному интерфейсу VSS, все программисты, работающие с данным проектом, сразу увидят, что указанный файл “принят” кем-либо из них. При получении файла на редактирование его можно заблокировать, т.е. запретить его редактирование другими программистами. Администратор проекта может включить автоматическую блокировку редактируемых текстовых файлов (в противном случае каждый текстовый файл может быть заблокирован разработчиком по желанию). Бинарные же файлы блокируются всегда.

CVS не предоставляет возможности отследить, кто и когда запросил из базы данных какой-либо файл. Тем не менее, узнать о том, что файл редактируется другим человеком, можно, при помощи команды “cvs watch” включив “наблюдение” за нужными файлами. После очередного приема файла из репозитория у каждого программиста на локальные копии “наблюдаемых” файлов будет установлен атрибут read only (или сняты права на запись в них под UNIX’ом). Выполнение программистом команды “cvs edit” разрешит запись в файл, одновременно отметив факт редактирования в БД проекта, а “cvs unedit” - снова запретит и уберет из БД отметку о редактировании файла. Некоторые редакторы, правда, и сами умеют снимать и устанавливать разрешение на запись, сообщая об этом пользователю, когда тот уже завершил редактирование и хочет сохранить изменения. Одна из возможных неприятностей: если кто-то начал редактировать файл до подачи вами команды watch, и пока не спешит заканчивать, то вы об этом можете узнать слишком поздно. Тем не менее, несмотря на указанные недостатки, данная тактика наиболее приемлема в условиях работы в режиме командной строки без графического интерфейса. Пользователь CVS, редактируя какой-либо файл, не может запретить другим разработчикам менять их локальные копии этого же файла. Однако он, при необходимости, может временно запретить другим запись этого файла в базу данных.

Пользователь CVS не может отправить в репозиторий файл, являющийся результатом редактирования более ранней версии, чем та, которая в данный момент находится в репозитории. Эта ситуация возникает в случае, когда за время редактирования вами какого-либо файла другой программист успел положить в репозиторий свою версию этого же файла. Для получения из репозитория последней версии файла используется команда “cvs update”. Если файл в репозитории не изменился, "cvs update" не будет ничего предпринимать; если локальная копия не изменена (или удалена), с сервера будет получена последняя версия файла; если изменился как локальный файл, так и файл в репозитории, будет запущена процедура решения конфликта изменений (см. следующий параграф). Для уменьшения вероятности возникновения конфликта версий рекомендуется регулярно выполнять упомянутую команду.

Пользователь COOP, только что присоединившийся к проекту, получает полную копию всех файлов у администратора – человека, который начал разработку проекта в COOP раньше других программистов. Все файлы проекта у него хранятся в выбранной им директории, причем на них устанавливается атрибут read only. При этом при операции check out COOP просто снимает атрибут read only с выбранного файла. По окончании работы с файлом при операции check in COOP возвращает на файл атрибут “только для чтения” и создает сообщение - скрипт (script) о том, какие изменения были внесены в этот файл, которое рассылается (обычно по электронной почте) всем участникам проекта, список которых программист получает у администратора. Пришедшие по почте (или иным путем) скрипты об изменениях, сделанных другими программистами, вручную или автоматически передаются запущенной программе COOP, которая изменяет локальные копии файлов в соответствии с содержимым этих скриптов. Все скрипты, которые создаются на машине данного разработчика или приходят к нему по почте, сохраняются в локальной базе данных проекта, благодаря чему программист может легко восстановить любую версию любого файла, проходившего через его руки. Таким образом, все основные действия над файлами производятся программистом в локальной копии проекта. Создатели Code Co-op не предусмотрели возможность блокировки файла для эксклюзивного редактирования, поскольку время оповещения об этом всех участников разработки было бы не определено.

 

Разрешение конфликтов изменений, внесенных в текстовый файл параллельно разными разработчиками

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

На стадии, предшествующей отправке такого файла в БД проекта (cvs update) CVS, если не в состоянии сама соединить версии, вставляет отчет о конфликтующих изменениях в данный файл так, чтобы можно было разрешить возникший конфликт при помощи удаления лишних строк. Например, если один добавил в файл MLK67W.CPP строчку

// We finished!!!           и отправит в базу данных, а второй в туда же напишет

// We finally crashed!!!!!!,   то после команды cvs update он увидит на месте своего изменения следующее:

Если VSS на этапе отправки такого файла в БД решит, что изменения, сделанные вторым программистом, можно автоматически объединить с изменениями первого, он об этом напишет и предложит просто отправить объединенный файл в базу данных. В противном случае будет вызвана программа визуального объединения двух текстовых файлов – достаточно удобный инструмент. Правда, есть в VSS одна ошибка: если один программист решает конфликт в каком-либо файле в течение длительного времени, то до окончания этой работы его коллега не сможет отправить в репозиторий свою версию того же файла. Ничего не подозревая об этом, проведя все стадии объединения версий файла, последний увидит сообщение вроде “file ... is already open” – тогда ему придется подождать и начать все заново, так как вся его работа по решению конфликтов будет потеряна. К счастью, такие случаи имеют место нечасто, объединение конфликтующих версий файла обычно проходит быстро, да и следующая версия VSS уже не за горами.

COOP действует в таких ситуациях следующим образом: если от другого разработчика пришел скрипт с изменениями файла, который вы редактируете, то после завершения редактирования после команды check-in ваши изменения будут помечены, как конфликтующие. Затем процедура разрешения конфликта версий вызовет утилиту визуального объединения текстовых файлов, если сама не сможет объединить две эти версии. Если два программиста одновременно рассылают скрипт с изменениями одного и того же файла, то один из двух конкурирующих скриптов будет отменен (сразу у всех участников проекта), и тому, чей скрипт отменили, придется заняться решением конфликтов, после чего попытаться послать скрипт снова.

Конечно, у данного подхода есть определенные минусы. Может, например, так случиться, что к вам приходит скрипт, конфликтующий в вашими изменениями в каком-то файле. Вы тратите (зря) некоторое количество времени на решение конфликта версий, а затем первый скрипт отменяется другим, пришедшим значительно позже вследствие медленной работы почты, скриптом. Или, например, ваши скрипты будут отменяться десяток раз подряд. Перечисленные неприятности случаются, тем не менее, достаточно редко, так что не приведут к значительным затратам времени, – почта обычно ходит достаточно быстро, а алгоритм выбора отменяемого скрипта достаточно продуман.

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

 

 

Работа с бинарными файлами

Системы коллективной разработки традиционно делят все файлы на два типа: текстовый и бинарный, причем при работе с бинарными файлами имеются значительные ограничения:

1)    В VSS невозможно одновременное редактирование бинарного файла двумя разными людьми (да и нежелательно, ведь объединение придется производить вручную, после явного получения нужной версии файла из репозитория). В CVS делать это, конечно, можно, но в официальной поставке нет возможности вызова внешних программ, позволяющих провести объединение изменений, внесенных в файл данного типа, так же обстоят дела в Code Co-op и большинстве остальных СКР.

2)    Расширение функциональности Code Co-op и VSS, которое могло бы разнообразить их работу с бинарными файлами в плане слияния конфликтующих версий, невозможно. Хотя стандартная поставка CVS также не предоставляет такой возможности, эта программа имеет общедоступный исходный код. Мне удалось, после некоторого общения с исходниками, научить CVS вызывать внешние программы для объединения файлов некоторых типов.

3)    При добавлении новых файлов в проект происходит автоматическое определение типа файла: текстовый или бинарный (по расширению, по наличию/отсутствию символов 0 или 10), - который также можно явно указать вручную. Если бинарный файл случайно отмечается как текстовый, то он может испортиться при передаче символов перевода строки между различными платформами, а также пострадать от утилит автоматического объединения конкурирующих текстовых файлов. Это накладывает дополнительную ответственность на разработчика, который впервые создает проект или добавляет туда новый файл.

 

Проекты и подпроекты. Ветвление. Система именования версий

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

У CVS база данных, вообще говоря, не разделена на проекты - она представляет из себя единое дерево файлов и директорий. Фактически структура проекта может быть задана на диске разработчика, поскольку каждая локальная директория может соответствовать любой (правда, только одной) директории в БД. Так можно собрать каждый проект из имеющихся в БД директорий и находящихся в них (не обязательно всех) файлов.

Для автоматизации этого процесса предназначен файл modules, хранящийся (чтобы сделать систему модулей идентичной для всех программистов) в репозитории CVS. Путем его редактирования можно задать модули – правила соответствия между локальными файлами и директориями, относящимися к данному модулю, и содержимым репозитория. В дальнейшем можно манипулировать всеми содержащимися в модуле объектами, передавая командам CVS лишь имя модуля. В частности, командой “cvs checkout имя_модуля” можно построить структуру проекта на локальном диске. Поскольку проекты и подпроекты существуют на диске пользователя в виде отдельных директорий и поддиректорий, модули являются единственным более-менее удобным способом единообразного для всех разработчиков задания проектов и подпроектов в CVS.

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

В VSS проект представляет собой просто структуру из файлов и директорий, которые на локальном диске хранятся в выбранной пользователем директории. Каждое поддерево в дереве проекта считается подпроектом, для которого, соответственно, можно определить свою, независимую от директории "родителя", рабочую директорию на локальном диске программиста. В любой момент файл из одного проекта можно добавить в другой средствами визуального интерфейса - при этом разработчики обоих проектов будут без проблем делить (share) этот файл. Единственное свойство подпроектов, выделяющее их из других проектов - наличие возможности располагать все подпроекты в соответствующих поддиректориях домашней директории родительского проекта при рекурсивном получении родительского проекта с сервера.

COOP не поддерживает проекты и подпроекты, также как и использование одного и того же файла в разных проектах.

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

В CVS создание ветви (branch) версий исходного кода производится командой rtag с ключом -b - при этом программист дает этой ветви текстовое имя, которое удобно использовать при получении файлов из репозитория.

В VSS какую - либо из предыдущих версий проекта можно скопировать в отдельный проект - и с этим новым проектом уже работать. Надо сказать, что хотя VSS и создает в своей БД отдельную копию для нового проекта, он запоминает, что данные файлы являются всего лишь другими версиями исходных. Это делает возможным достаточно быстрое слияние двух параллельных версий проекта в одну. Разумеется, даже для одного файла можно одновременно поддерживать несколько версий, если его сначала сделать общим для двух проектов, а затем применить команду branch.

В системе Code Co-op можно только выделить текущую версию проекта в отдельный проект, и разрабатывать ее независимо.

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

Таким образом, создателям СКР не составляет особого труда поставить в соответствие внутренним версиям файлов пользовательские имена версий, в том числе поименованные текстом.

CVS предоставляет следующие возможности:

·         присвоение файлу или группе файлов (последней версии) текстового имени версии;

·         присвоение последним на момент времени, указанный пользователем, версиям файлов, текстового имени версии;

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

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

COOP не предоставляет возможности текстового или какого-либо еще именования версий (видимо, это показалось создателям данной СКР ненужным).

 

Интегрируемость с другим программным обеспечением

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

a)    вызова нужных программ (в основном редакторов) средствами СКР;

b)    исполнения команд СКР изнутри других программ;

c)    перехвата действий, производимых СКР, определенными пользователем программами, в том числе определения средств, автоматизирующих поиск различий (differing) в конфликтующих версиях файлов некоторых типов и, возможно, слияние этих версий (merging).

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

VSS позволяет переопределить, во первых, редактор для ввода сообщений, во вторых, программы просмотра и редактирования текстовых файлов, вызываемые непосредственно из визуальной оболочки VSS. Для файлов других типов вызываются редакторы, зарегистрированные в используемой операционной системе (обычно Windows или MacOS). Все производимые пользователем команды могут быть продублированы из командной строки, что делает возможной интеграцию с другим ПО. Использование внешних средств сравнения и объединения файлов невозможно.

COOP не имеет интерфейса командной строки и возможности использования каких-либо внешних программ, кроме редакторов.

 

Контроль доступа к файлам

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

Если доступ к файлам осуществляется средствами файловой системы, то и контроль доступа к БД проекта осуществляется на основе средств этой ФС.

Когда для доступа к репозиторию используется программа-сервер БД, то ограничения доступа к файлам проекта устанавливаются путем настройки репозитория.

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

 

Другие средства разработки

Вышеприведенный обзор включает всего три средства коллективной разработки, хотя всего таких программ, конечно, гораздо больше. В таблице 1 приведена таблица возможностей некоторых коммерческих СКР, а в таблице 2 - некоммерческих. К сожалению, все имеющиеся средства перечислить невозможно. Достаточно полный список ссылок на сайты производителей СКР можно найти по адресу http://www.cs.colorado.edu/users/andre/configuration_management.html. К моменту прочтения вами этой статьи представленные здесь данные могут несколько устареть, однако общая картина, я думаю, сохранится.

 

Название программы

VC

Cnf

Brn

Shr

Net

FS

Srv

cmd

GUI

jc

Bc

Bt

Price

Perforce

+

+

+

-

+

-

S

+

-

+

-

-

$500

GP-Version

+

-

+

+

+

+

S

-

+

-

P

+

$325

MKS Source Integrity P.E. 3.1

+

+

+

?p

+

+

S

+

+

+

+

?-

$599

Code Co-op 2.0

+

+

-

-

*

+

W

-

+

-

-

-

$150

CS-RCS

+

-

+

-?

+

+

S

-

+

-

-

-

$75

PVCS Version Manager

+

-

-

-

-

+

S

=

+

-

-

-

~$620

StarTeam

+

+

+

+?

+

+

S

?-

+

+

-

+

~$650

VERSIONS 2.0

+

+

+

-?

-

+

S

-

+

-

-

-

~$220

TLIB 5.5

+

+

+

-

-

+

S

+

=

-

-

-

$225

Visual SourceSafe 6.0

+

+

+

+

*

+

S

+

+

-

-

-

$549

Таблица 1. Коммерческие средства разработки

 

Название программы

VC

Cnf

Brn

Shr

Net

FS

Srv

Cmd

GUI

Jc

Bc

Bt

Lic

Revision Control System (RCS)

+

-

+

-

-

+

S

+

-

-

-

-

GNU

Concurrent Versions System (CVS) 1.10

+

+

+

+

+

+

S

+

*

-

-

-

GNU

CSSC (free version of SCCS)

+

-

+

-

-

+

S

+

-

-

-

-

GNU

Proj. Rev. Control System (PRCS)

+

+

+

+

-

+

S

+

-

-

-

-

GNU

Aegis (by Peter Miller) 3.12

+

+

+

-

*

+

B

+

-

-

+

-

GNU

Таблица 2. Некоммерческие СКР

 

 

 

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

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

Повсеместное распространение сети Internet сделало возможным совместную разработку ПО людьми, находящимися за тысячи километров друг от друга. Сразу появилась проблема эффективного контроля версий без необходимости поддержки постоянного сетевого соединения (к слову сказать, достаточно дорогостоящего). Самый крайний подход к решению этой проблемы демонстрирует программа Code Co-op – здесь был произведен полный отказ от использования центрального репозитория. Программа Aegis (написанная Питером Миллером – прошу не путать с одноименным продуктом для торговых организаций) предоставляет возможность работать как с использованием центрального сервера, так и без него. Многие продукты, например MKS Source Integrity Pro и StarTeam, предоставляют разработчику возможность удаленного доступа к серверу при помощи достаточно оригинального средства – Web-браузера.

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

 

Практические рекомендации.

К выбору средств коллективной разработки, которые вы будете использовать, надо подходить очень осторожно. Неправильный выбор может повлечь за собой как огромные потери времени на освоение и настройку СКР, так и необоснованно высокие затраты на приобретение программ, у которых вы не будете использовать все имеющиеся возможности. Как видно из таблицы 1, цена за одно рабочее место пропорциональна количеству "плюсиков". С другой стороны, практика показывает, что поставщики относительно дорогого ПО предлагают достаточно качественную техническую поддержку. Это поможет тем, кто впервые связался с СКР, сэкономить значительное количество времени. Многие разработчики все же делают выбор в пользу недорогих СКР.

Следующим вопросом является выбор между работой в командной строке и графическим интерфейсом. Любое пожелание на этот счет можно оспорить. Если большая часть разработчиков в вашем коллективе может быстро набирать команды СКР на клавиатуре, то системы вроде Perforce или CVS - это для вас. Большинству все же удобнее работать с графическим интерфейсом. Тут, правда, есть одна тонкость: большая часть средств коллективной разработки имеет графический интерфейс только в версиях для операционной системы Windows. Практически все коммерческие СКР обладают этой особенностью.

Некоммерческие СКР, разработка которых годами велась под UNIX'ом, не имеют графического интерфейса. Тем не менее, благодарные пользователи понаписали множество внешних утилит, предоставляющих возможность производить часть операций все же не в командной строке, а с использованием графического интерфейса. Чемпионом по количеству таких утилит - около 5 - является CVS (что свидетельствует о популярности). Стоит отметить WinCVS (Win32, MacOS) и JCVS (Java).

Если вы не хотите тратить деньги – пользуйтесь CVS или PRCS.