Искусство программирования для Unix

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

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

15.5.2. Контроль версий вручную

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

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

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

15.5.3 Автоматизированный контроль версий

Для того чтобы избежать описанных выше проблем, можно использовать какую-либо систему контроля версий (Version-Control System— VCS), пакет программ, который автоматизирует большую часть рутинной работы по поддержанию аннотированной истории проекта и позволяет избежать конфликтов модификации.

Большинство VCS-систем используют одну и ту же базовую логику. Использование такой системы начинается с регистрации семейства файлов исходного кода, т.е. с указания VCS-системе начать архивирование файлов, описывая историю их изменения. После этого при необходимости отредактировать один из таких файлов требуется отметить (check out) данный файл — объявить его исключительную блокировку. По окончании редактирования необходимо сдать (check in) файл, добавляя внесенные изменения в архив, снимая блокировку и вводя комментарии, поясняющие суть внесенных изменений.

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

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

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

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