Важность использования меток
Одной из наиболее важных команд, применяемых в системе управления версией, является команда метки (label command). В системе Microsoft Visual SourceSafe метку называют "label" (метка), в MKS Source Integrity — контрольной точкой (checkpoint), а в PVCS Version Manager — меткой версии (version label). Различные системы управления версиями, как мы только что видели, могут ссылаться на команду метки различными способами, но независимо от того, как она называется, метка отмечает некоторый набор главных источников. Метка позволяет отыскать и извлечь отмеченную ею версию главных исходных файлов в будущем. Если при отметке вы сделаете ошибку, то можете навсегда потерять возможность идентифицировать главные исходные файлы, используемые индивидуальной версией, а следовательно, обнаружить, почему специфическая версия завершается аварийно.
Решая вопрос о том, что нужно помечать, я всегда следовал следующим трем правилам:
1. Помечайте все внутренние опорные точки.
2. Помечайте любую конфигурацию продукта, которая посылается кому-то вне команды.
3. Помечайте любые ежедневные версии проекта Во всех случаях я использую следующую схему:
<имя-проекта> <Отметка/Причина> <Дата>
поэтому имена меток становятся описательными. Что касается первых двух правил применительно к рассмотренным выше этапам разработки, то по окончании второго и третьего (желтого и красного) этапов применение меток обязательно.
О третьем правиле установки меток многие забывают. Инженеры по качеству обычно работают с ежедневными построениями так, что когда они сообщают о проблеме, она относится к специфической версии главных источников. Поскольку разработчики могут изменять код быстро, желательно, чтобы они имели возможность достаточно просто возвращаться к точной версии файлов, в которых им нужно воспроизвести ошибку.
Общий вопрос отладки
Что делать, если возникают трудности с воспроизведением конфигураций для программистов, не входящих в команду?
Компилируя проект для кого-то, кто не входит в команду, необходимо сделать полную копию каталога сборки проекта на компакт-диск или ленту. Эта копия должна включать все исходные файлы, промежуточные файлы, файлы символов и окончательный вывод (final output). Кроме того, в нее также следует включить комплект установки, который был послан заказчику.
Даже сделав все возможное, чтобы сохранить специфическую конфигурацию в системе управления версией, нельзя быть уверенным, что в результате повторной сборки проекта будут получены двоичные файлы, идентичные исходным. Архивированием полного дерева конфигураций можно отлаживать проблемы пользователя точно с теми же двоичными данными, которые были отосланы.
