Управление версиями


Получение старых версий

Если различия между двумя версиями файла слишком велики, их просмотр может оказаться непростым делом. В некоторых случаях diff не в состоянии предоставить достаточный контекст, чтобы понять эти изменения. В подобной ситуации проще будет получить старую версию файла и ознакомиться с ней. Чтобы извлечь старую версию файла из RCS, следует использовать ключ -r. Номер версии следует указывать сразу вслед за ключом -r, без пробела:

# co -r1.1 rc.conf
rc.conf,v --> rc.conf
revision 1.1
done

Здесь была извлечена версия 1.1, которая перезаписала существующий файл rc.conf.

Минутку! Перезаписывать существующие файлы, особенно те, что имеют жизненно важное значение для системы, — это неправильно. Чтобы указать иное место сохранения извлекаемого файла, следует использовать ключ -p, благодаря которому содержимое файла будет выводиться на экран, и этот вывод можно перенаправить в файл.

Здесь выполняется получение файла rc.conf версии 1.1 (1), благодаря наличию ключа -p (2) содержимое файла будет выводиться непосредственно на терминал. Правая угловая скобка (>) (3) перенаправляет вывод в файл, в данном случае /tmp/rc.conf.original.

Снятие блокировок

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

Как потенциальный взломщик блокировок, вы должны быть предусмотрительны. Если кто-то действительно вносит изменения в файл в то время, как вы снимаете блокировку, то хозяина это не только не обрадует, но и серьезно разозлит. Поэтому постарайтесь сначала найти этого человека, прежде чем снимать блокировку! Однако, если вы все-таки решили снять блокировку, запустите для выбранного файла команду rcs -u. RCS попросит ввести сообщение, объясняющее причину снятия блокировки, которое будет послано по электронной почте пользователю, заблокировавшему файл.*

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

Автоматизированный поиск блокировок

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

Получение нескольких файлов

Регистрация сразу нескольких файлов, участвующих в едином изменении, — довольно редкая ситуация. Например, изменение в DNS может потребовать вносить изменения сразу в два или более файла зон (глава 14). Для этих файлов обычно требуется оставить одно протокольное сообщение, а вам едва ли захочется вводить его несколько раз. Для примера я зарегистрирую файлы blackhelicopters.org.db и absolutefreebsd.com.db с протокольным сообщением update for new mail server.

# ci -u -m»update for new mail server» blackhelicopters.org.db absolutefreebsd.com.db

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

RCS и строки идентификации

Строки идентификации (ident strings) позволяют упростить просмотр сведений о том, кто и когда изменял тот или иной файл. Так, если последнюю неделю сервер ведет себя странно, полезно знать, что изменилось неделю назад. Конечно, можно запустить rlog(1) для каждого конфигурационного файла системы и проанализировать изменения, но это немного утомительно. Куда лучше просто взглянуть на файл, в котором представлена вся необходимая информация. Вот где нужны строки идентификации. Эти строки можно поместить в файлы, сохраняемые в RCS. Когда пользователь захватывает файл, RCS автоматически обновляет эти строки.

Строки идентификации имеют формат $string$. Например, в строке $Id$ размещается информация о последнем изменении в файле. Всегда полезно разместить #$Id$ в первой строке важных конфигурационных файлов, таких как /etc/rc.conf. Первый символ # сообщит сценарию /etc/rc, что это комментарий и строку следует пропустить, но когда файл будет зарегистрирован в RCS, она примет следующий вид:

Простая строка идентификации была дополнена системой! Здесь можно увидеть номер версии файла (1), дату (2) и время (3) последнего изменения и имя пользователя, выполнившего это изменение (4). Это дает возможность легко ответить на вопрос: «Файл изменялся, и с кем теперь нужно поговорить об этом изменении?» Последний элемент строки — состояние RCS, произвольная строка, которую можно назначить с помощью ci(1) или rcs(1). Для файла можно задать произвольные состояния, которые позволяют понять назначение файла и условия его использования. Многие люди применяют эту строку, чтобы пометить файл как «экспериментальный» или «рабочий» или указать: «Ничего не меняйте ни по каким причинам». Обычно в системном администрировании строка состояния RCS не применяется.

Строка идентификации $Id$ встречается чаще всего, но имеются и другие строки подобные строки, например $Header$ и $Log$. $Header$ сходна с $Id$, за исключением того, что она сообщает полный путь к файлу RCS, а не просто имя файла. $Log$ — интересная строка идентификации, добавляющая протокольные сообщения RCS к самому файлу; при просмотре файла эти сообщения можно увидеть. Они могут переполнять интенсивно редактируемые файлы, но могут быть полезными для файлов, которые изменяются редко. Так, /etc/rc.conf на рабочей системе может вообще не изменяться месяц. Если описываемую строку идентификации поместить в этот файл, в нем можно будет просматривать все протокольные сообщения RCS. Сразу станет ясно, что изменено, кем и почему. Большинство других строк идентификации по сути являются подмножеством строк $Id$, $Header$ и $Log$. Полный перечень строк идентификации вы найдете в странице руководства ident(1).

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

Комментарии запрещены.