Запомнить всё

Тот, кто пробовал в течение некоторого времени поддерживать какую-нибудь статью в Википедии, может спеть пусть короткую, но очень вдохновенную песню о том, что хранение полной истории версий – абсолютно гениальная вещь.

Мы более-менее приучены делать бэкапы перед важными изменениями. Но учитывая сложность современной информации, кто может точно сказать заранее, какое изменение будет важным? Поменяли одну часть текста (программы, например) – другая часть испортилась. В случае совместной работы ситуация приобретает катастрофические масштабы, оттого что разные люди, развивая каждый свои переделки, могут одновременно менять один файл – и такие ситуации нужно хотя бы просто отслеживать, чтобы можно было проверить качество результата.
Соответственно, появляется, во-первых, нужда хранить промежуточные версии файлов, во-вторых, предупреждать об изменениях в проекте, внесённых другими участниками. Эти функции объединяет в себе софт, называемый системой контроля версий (Version Control System, VCS).
Первые системы управления версиями появились задолго до Wiki и ведут род из суровых консолей Unix: SCCS (Source Code Control System) была разработана в 1972 году. За ней последовали RCS, CVS и наконец – Subversion (SVN), которая стала стандартом в мире open source. О ней мы сегодня и поговорим.

Как это делается
Версии файлов обозначаются с помощью номеров версий (revision number). В SVN номер версии присваивается всему репозиторию (хранилищу файлов проекта), соответственно выгруженные из репозитория файлы можно обозначить как соответствующие определённой версии проекта.
Разработчик, присоединяющийся к проекту (или, как частный случай, – только что начавший проект) скачивает себе текущие версии файлов (или пустой репозиторий). Скачанные файлы, лежащие у разработчика, называются рабочей копией. После внесения изменений в свою рабочую копию (в том числе, добавления файлов в проект) он загружает эти изменения в репозиторий.
Если при загрузке файлов обнаруживается, что кто-то уже поработал над этими же файлами, загрузка в репозиторий отменяется, а разработчик должен выяснить, конфликтуют ли его изменения с изменениями другого автора. В случае нужды – связаться с этим автором и обсудить проблему; затем внести в свою рабочую копию окончательные изменения, сообщить системе контроля, что он разрешил конфликт и наконец, загрузить файлы (см. схему на рис. 1).

20080205_1.jpg
Рисунок 1

Разработчик скачивает себе изменения, внесённые другими участниками проекта, чтобы иметь у себя проект в текущей стадии развития, вносит в файлы новые изменения – и так далее по кругу.
В случае нужды, всегда можно проверить, кто и когда внёс определённые изменения в репозиторий и просмотреть содержание внесённых изменений. Можно целиком выгрузить себе файл по состоянию на определённый момент (версию).
Таким образом, система контроля версий обычно предоставляет следующие функции:
– хранение предыдущих версий файлов;
– сравнение различных версий для выявления внесенных изменений;
– обеспечение совместного доступа к единому хранилищу файлов проекта, т.е. скачивание файлов и чужих изменений разными участниками;
– документирование изменений, в частности дата и автор изменений между двумя версиями файлов;
– обнаружение конфликтов при загрузке изменений.

Аудитория
Некоторые из возможностей относятся только к совместной работе над проектами, однако то, что касается собственно хранения версий файлов, изменяющихся в работе, может быть полезно и для одного человека, если плод его труда склонен сильно изменяться в процессе работы, причём, нужно отслеживать, а то и документировать эти изменения.
Системы контроля версий наиболее распространены среди программистов, поскольку, во-первых, код программы обычно очень динамичен (причём, удачная реализация какой-то функции запросто может быть потёрта в ходе дальнейшей разработки), ошибки же одновременно чреваты и трудно отслеживаемы; а во-вторых, по традиции Unix, популярные системы контроля версий отлично заточены под управление небольшими текстовыми файлами (отслеживание добавленных/изменённых строк, загрузка в репозиторий только изменённых частей файла).
В современной развитой разработке ПО система контроля версий органически вписывается (и зачастую интегрирована) в среды разработки, такие как Rational Rose, – объединяющие в себе все функции по управлению процессом разработки программы: планирование и проектирование, создание кода, документирование изменений в проекте, генерацию исполняемых файлов. SVN не относится к таким средам, хотя и может использоваться с ними. Подобные среды имеют собственные системы хранения и контроля версий, по крайней мере, для вспомогательной документации проекта – планов и проектов.
SVN отходит от традиции управления текстовыми файлами и, в частности, более эффективно хранит двоичные данные – а соответственно, может использоваться для любых типов данных, изменяющихся в процессе разработки: изображений, аудио- и видеопроектов и пр.

Использование SVN
Subversion как программа представляет собой набор утилит, работающих в командной строке, которые используют несколько библиотек, реализующих основные функции собственно системы: клиентская библиотека (занимается управлением рабочей копией), репозиторий (управляет хранилищем) и несколько низкоуровневых библиотек. Клиент и репозиторий могут связываться через специальный сервер svnserve, через WebDAV с помощью веб-сервера Apache, или же
клиент может непосредственно связываться с репозиторием, расположенным на той же машине.
Благодаря разделению на библиотеки, существуют несколько графических интерфейсов к системе, плюс библиотека может быть интегрирована в среду разработки или редактор. Наиболее популярные фронтенды для Windows – TortoiseSVN и RapidSVN. Есть клиенты, выполненные в виде веб-интерфейсов. Также некоторые компании предлагают создание и хостинг репозиториев на своих серверах (наиболее известная из них – SourceForge, Inc; у неё собственная система версий, но доступ можно получить с помощью CVS или SVN).
Итак, использование SVN из командной строки предполагает запуск утилиты с определёнными командами, например: svn checkout file:///t:/proj/vim/maximize/svn скачает файлы из репозитория в текущую директорию; svn status выведет данные о том, что изменилось, добавилось или было удалено в рабочей копии. svn commit запросит пояснительный текст для изменений и затем зальёт изменения в репозиторий. svn update – обновит рабочую копию из репозитория. Команда svn diff с различными параметрами служит для сравнения изменений и рабочей копии: просто svn diff выведет изменения в файлах с последнего апдейта, а svn diff -r 15:16 include/helper.c скажет, что было сделано с файлом helper.c между 15 и 16 версиями проекта. Репозиторий создаётся с помощью отдельной программы: svnadmin create file:///t:/proj/vim/maximize/svn.
Помимо того, что неудобно постоянно набирать одни и те же команды в консоли, так ещё и в Windows возникают проблемы с русскими кодировками в пояснениях к изменениям. Поэтому рекомендуется использовать один из графических клиентов, описанных далее.
Самый проработанный и удобный, особенно для поклонников Total Commander клиент – TortoiseSVN, интегрирующий команды SVN в контекстное меню файлов и папок, а кроме того, добавляющий поверх иконок файлов оверлеи, сигнализирующие о состоянии файлов в рабочей копии в сравнении с репозиторием (изменены, добавлены/удалены). Также в диалогах TortoiseSVN (см. рис. 2) есть такие удобства, как просмотр изменений в файлах прямо перед закачкой их в репозиторий; проверка правописания при написании пояснений к изменениям и автоподстановка имён файлов и названий функций/переменных из файлов (!); диаграмма версий и ответвлений проекта.

20080205_2.jpg
Рисунок 2

TortoiseSVN имеет собственный (удобный) интерфейс сравнения файлов, но может использовать стороннюю программу WinMerge.
Для людей, более привыкших к интерфейсу Explorer, может подойти один из клиентов, выполненных в виде отдельных программ и представляющих команды SVN в виде меню и кнопок на панелях инструментов. К несчастью, все они имеют значительные недостатки: во многих нельзя даже толком обозреть изменения перед закачкой, ни один не умеет создавать репозитории. Open source?клиенты: RapidSVN, QSvn, Subcommander.
Коммерческие: Syncro SVN Client (очень медленный) и SmartSVN (не поддерживает локальные репозитории; существует урезанная бесплатная версия). Многие из этих клиентов могут использовать для сравнения файлов WinMerge.
Существует плагин к FAR Manager для работы с Subversion (http://www.megabyte-web.ru/goto/ChZEQVwWHwMNBRRQDxcBXlkfFkdbVFRRXVxE/), функционал чуть ниже, чем у GUI?фронтендов, нельзя работать с репозиториями (в том числе просматривать без скачивания). Для Total Commander есть FS-плагин для доступа к CVS (http://www.megabyte-web.ru/goto/ChZEQVwWHxYLDwVYAhcQRBtACURSRVFWXx1zNWJ1R1wVEVVDOQgeUUxUSF0SVA4=/), для SVN – нет.

Другие системы
Другие популярные системы контроля версий – MS Visual SourceSafe (интегрируется с Visual Studio, предназначена для небольших проектов и лишена многих функций современных VCS), IBM Rational ClearCase (для больших компаний). Из открытых VCS активно развиваются децентрализованные, т.е. проект не располагается на каком-то одном сервере: GNU arch, Monotone, Bazaar, SVK и др. Из проприетарных децентрализованных систем известна BitKeeper (использовавшаяся в работе над ядром Linux, но заменённая на Git, созданный Торвальдсом).

Хозяйке на заметку
Текстовый редактор Vim в седьмой версии довёл до абсолюта идею Undo. Обычно, если вы ввели текст, затем, передумав, отменили изменения и начали другие, первый вариант изменений канет в Лету. Vim же теперь запоминает все варианты текста и позволяет вернуться к любому из них. Всякая мысль, введённая было в текст, уже не исчезнет до окончания работы с редактором.
По сути, эта функция улучшает контроль над версиями на коротком временном промежутке между ревизиями, вносимыми в репозиторий SVN.


Рекомендуем почитать: