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

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

Самое главное достоинство таких систем состоит в том, что из них не может исчезнуть информация. Т.е. всегда можно вернуться к однажды сохраненной версии файла, независимо от того, какие изменения были в него внесены.

Рассмотрим простой пример. Допустим, вы делаете web страницу. Проект состоит из трех файлов (с разметкой, таблицей стилей и скриптами). На каком-то этапе вы получили приемлемый внешний вид, но решили немного поэкспериментировать. Естественно эти эксперименты затронут все три файла, причем изменения будут внесены в различные их части.

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

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

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

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

Но эта статья об использовании систем управления версий при индивидуальной разработке, поэтому проблемы команд мы здесь рассматривать не будем.

Думаю, теории достаточно, переходим к реализации.

Выбор системы контроля версий

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

Установка и настройка Subversion

Здесь все предельно просто. Качаете с официального сайта дистрибутив и запускаете инсталлятор.

После установки вы сможете работать… но только через консоль. Естественно, это позволяет детально изучить работу системы, но вводить каждый раз имена файлов… мягко говоря, не очень удобно .

Поэтому советую сразу скачать какой-нибудь графический клиент для Subversion. Полный их список находится здесь.

Я пользовался двумя:
1) Subclipse – это плагин для Eclipse(http://www.eclipse.org/), т.е. для его использования нужна эта IDE.
2) TortoiseSVN – это более универсальная оболочка. Она встраивается в "Проводник" Windows. При этом к иконкам файлов добавляются значки, отображающие текущее состояние файла, а команды можно выполнять из контекстного меню.

Теперь нужно создать хранилище

Для этого создаем новую папку, например, e:\docs\svn.
И, находясь в этой папке, выполняем команду:
svnadmin create my_project
Эта операция создаст папку "e:\docs\svn\my_project" со служебными файлами хранилища.

Примечание. Если вы используете какой-нибудь клиент, ищите пункт Create Repository.

Перед отправкой файлов в хранилище очень желательно определиться со структурой проекта

Это, наверное, самый сложный этап для новичков (по себе знаю ).

Чтобы не морочить вам голову теорией приведу пару примеров, которые должны подойти для небольших проектов.

Первый пример. Используем две папки:
trunk/ – для размещения законченной (стабильной) версии (ветки) проекта;
branches/ – эта папка будут использоваться для экспериментов, т.е. в ней вы будете создавать папки с экспериментальными версиями проекта. Если вы решите, что какая-нибудь из этих версий должна заменить основную, то просто перенесете ее в trunk.

Второй пример удобно использовать, если нужны две версии проекта, различающиеся только несколькими файлами. Например, вы создаете web сайт, использующий базу данных. Параметры подключения к этой базе на вашем компьютере и на сервере будут отличаться, но не изменять же их каждый раз вручную.
Тут удобно использовать три папки:
trunk/
branches/
trunk_for_server/ - копия папки trunk для сервера (отличаются только файлы с параметрами подключения).
Перед закачкой файлов на сервер вы просто "сливаете" нужные изменения из trunk в trunk_for_server.

Примечание. Оба приведенных примера это только возможные варианты. Вы можете придумать свою структуру.

Переходим к созданию выбранной структуры в хранилище

Для этого создаем временную папку, например, e:\temp, а в ней пустые папки, соответствующие выбранной структуре.
Например, если вы остановились на первом варианте:

e:\temp\trunk
	\branches

Теперь, находясь в папке "e:", выполняем импорт этих папок в хранилище.
svn import temp file:///e:/docs/svn/my_project -m "Начальный импорт"

Удаляем e:\temp.

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