27.3. Управление изменениями
Любой разработчик, которому приходилось работать в команде по разработке Web-приложения, знает о трудностях распределения задач между членами группы разработки с психологической точки зрения. В небольших командах достаточно переклички в одной комнате. Для больших команд, вероятно, потребуется отдельный менеджер для координации процесса разработки. Однако диаграммы Ганта, кажется, не совсем подходят для менталитета "недальновидного" типичного Web-програм-миста. Для него совершенно естественно просматривать файлы проекта, меняя их содержимое по своему усмотрению, не заботясь о том, что кто-то в это время тоже может редактировать их.
Иногда изменения теряются, но профессионалы работают с резервным копированием. В противном случае члены коллектива могут предупредить друг друга не использовать конкретные файлы в определенный период времени. Если файл был разрушен, то необходимо отыскать более старую версию. Разработчики могут подстраховаться, сохранив свои собственные локальные копии каждого изменения, внесенного ими, но это может привести к еще большей неразберихе.
Процесс создания Web-узла предусматривает множество итераций. Команда работает над реализацией проекта и интегрирует изменения после завершения работы. Есть два способа внедрения изменений в производство. Один из них - метод грубой силы, который предполагает замену всех файлов приложения. Такой подход гарантирует, что ни один файл не будет пропущен. С другой стороны, можно копировать только те файлы, которые не изменялись, и файлы, которые претерпели изменения.
Вместо того чтобы пробовать контролировать исходные коды случайным образом, рассмотрим применение специальной системы контроля исходными кодами. Популярная среди программистов, работающих с языком C, система контролирования исходных кодов работает и для большинства других языков программирования. Так, коллектив разработчиков PHP применяет систему контроля исходных кодов для координации работы сотен людей, вносящих свой вклад в развитие PHP. Это справедливо и для множества проектов открытых программных средств.
Наиболее популярной системой управления разработкой открытых программных средств является CVS (Concurrent Versions System - система параллельных версий). CVS сама по себе является открытой системой, в основе которой лежит функциональность утилит diff и patch, входящих в состав большинства операционных систем. Утилиту diff можно использовать для сравнения двух файлов и отображения различий между ними. Утилита patch может применить эти различия к третьему файлу и на основании этого модифицировать его.
Система CVS содержит репозиторий проекта, в котором хранятся все модификации всех файлов. Пользователи взаимодействуют с репозиторием на сервере с помощью обычных команд оболочки. Удаленные пользователи по умолчанию используют удаленную оболочку, или rsh. Предпочтительнее по возможности пользоваться оболочкой ssh, так как rsh отправляет пароли и трафик по сети в незашифрованном виде. Некоторые открытые проекты для сбора текущих версий используют одну учетную запись, не позволяющую вносить изменения.
После проверки файлов из репозитория разработчик может внести любое количество изменений в файлах, не беспокоя при этом других разработчиков. При нормальном использовании система CVS не гарантирует исключительное использование файла одним пользователем. Такой режим работы называется работой с незарезервированными копиями. Разработчики работают с файлами параллельно, а система CVS берет на себя заботу о контроле за изменениями. Система CVS распространяет внесенные изменения по запросам разработчиков. Изменения интегрируются в исходные файлы, даже если разработчик вносит изменения в файлы, которые никогда не проверялись. 
Система CVS поддерживает создание резервных копий, однако большинство поль­зователей не видят в них смысла. В большинстве случаев система CVS может устранить различие в файлах без какого-либо вмешательства. При обнаружении конфликта система CVS предупреждает разработчика и помечает проблемный код.