15.5.4.2. Revision Control System (RCS)
Список превосходных альтернатив с открытым исходным кодом начинается с системы RCS (Revision Control System — система управления ревизиями), которая была создана в Университете Пурдью через несколько лет после SCCS и первоначально распространялась с 4.3BSD Unix. Данная система логически подобна SCCS, но имеет более четкий командный интерфейс и хорошие средства для группировки целых редакций проекта под символическими именами.
RCS в настоящее время является наиболее широко используемой системой в мире Unix. В некоторых других Unix-системах контроля версий RCS используется в качестве серверной части или базового уровня. Она хорошо подходит для проектов, разрабатываемых одним разработчиком или небольшой группой разработчиков, находящихся в одной лаборатории.
Исходные коды RCS курируются и распространяются FSF. Существуют бесплатные версии для операционных систем Microsoft и VAX VMS.
15.5.4.3. Concurrent Version System (CVS)
CVS (Concurrent Version System — система параллельных версий) была разработана в начале 1990-х годов как клиентская часть к RCS, но модель контроля версий, которая использовалась в ней, настолько отличалась, что данная система была немедленно квалифицирована как новая конструкция. Современные реализации не основываются на RCS.
В отличие от RCS и SCCS, система CVS не выполняет исключительную блокировку файлов, когда они отмечаются разработчиком для редактирования. Вместо этого система пытается автоматически согласовать не противоречащие друг другу изменения во время сдачи файлов, а в случае возникновения конфликтов требует вмешательства пользователя. Такая конструкция работает, поскольку конфликты заплат гораздо менее распространены, чем можно было бы предполагать.
Интерфейс CVS значительно более сложен, чем интерфейс RCS, и требует большего дискового пространства. Данные свойства делают систему неудачным выбором для небольших проектов. С другой стороны, CVS хорошо подходит для крупных проектов с участием множества разработчиков, распространенных по нескольким участкам разработки, которые связаны друг с другом посредством Internet. CVS-инструменты на клиентской машине можно легко настроить на непосредственное взаимодействие с репозиторием, расположенным на другом узле.
В сообществе открытого исходного кода система CVS интенсивно используется для таких проектов, как GNOME и Mozilla. Обычно такие CVS-репозитории позволяют любому разработчику отмечать исходные файлы удаленно. Следовательно, кто угодно может создать локальную копию проекта, модифицировать ее и отправить заплаты с изменениями по почте кураторам проекта. Реальный доступ на запись к такому репозиторию более ограничен и должен быть явно предоставлен кураторами проекта. Разработчик, имеющий такой доступ, может обновить проект из своей модифицированной локальной копии, в результате чего локальные изменения вносятся непосредственно в удаленный репозиторий.
Пример хорошо организованного CVS-репозитория, доступного через Internet, можно посмотреть на сайте GNOME CVS <http://cvs.gnome.org>. На сайте иллюстрируется использование инструментов быстрого просмотра с поддержкой CVS, таких как Bonsai, которые полезны тем, что способствуют координации работы крупной и децентрализованной группы разработчиков.
Общественная структура и философия, сопровождающие использование CVS, являются настолько же важными, насколько подробности использования инструментов. Предполагается, что проект будет открытым и децентрализованным, а код будет предметом экспертной оценки и изучения даже со стороны разработчиков, которые официально не являются членами проектной группы.
Не менее важна 'неблокирующая' философия CVS, которая означает, что проект не может быть заблокирован в случае, если программист покинет его на полпути, не разблокировав модифицируемый им файл. Таким образом, CVS позволяет разработчикам избегать 'единоличной точки сбоя'. В свою очередь, это означает, что границы проекта могут быть 'плавающими', эпизодическое участие в проекте является сравнительно простым, и для проектов не требуется сложная управленческая иерархия.
Исходные коды системы CVS сопровождаются и распространяются FSF.
CVS имеет значительные проблемы. Некоторые из них являются просто ошибками реализации, однако основная проблема заключается в том, что пространство имен файлов проекта не контролируется тем же способом, что и изменения в файлах. Поэтому CVS легко запутать переименованием, удалением и добавлением файлов. Кроме того, CVS регистрирует изменения для каждого файла, а не для групп изменений файлов. Это усложняет возврат к определенным версиям и обработку частичного возвращения файлов. Вместе с тем, ни одна из указанных проблем не является собственной для неблокирующего стиля, и такие проблемы успешно решаются более новыми системами контроля версий.
15.5.4.4. Другие системы контроля версий
Конструктивные проблемы системы CVS достаточны для того, чтобы создать потребность в лучших VCS-системах с открытым исходным кодом. Несколько таких проектов полным ходом разрабатывались в 2003 году. Наиболее выдающимися из них являются проекты Aegis и Subversion.
Проект Aegis <http://www.pcug.org.au/~millerp/aegis/aegis.html> имеет самую длинную историю среди CVS-альтернатив и является зрелой действующей системой. С 1991 года данная система обеспечивает контроль версий для самого проекта Aegis. Особый акцент в этой системе сделан на возвратное тестирование и проверку достоверности.
Система Subversion <http://subversion.tigris.org/> позиционируется как 'правильно сделанная CVS', с полностью разрешенными известными конструктивными проблемами. В 2003 году данная система имела наилучшие перспективы заменить в ближайшем будущем CVS.
Проект BitKeeper <http://www.bitkeeper.com> исследует некоторые интересные конструктивные идеи, связанные с группами изменений и множественными распределенными репозиториями кода. Линус Торвальдс использует Bitkeeper для исходных кодов ядра Linux. Однако лицензия (отличная от лицензий на открытый исходный код) на данную систему является спорной и значительно задерживает признание данного продукта сообществом.
15.6. Отладка времени выполнения
Каждый, кто занимается программированием больше одной недели, знает, что исправление синтаксических ошибок является простой частью отладки. За ней следует сложная
