Категории: Subversion

В этой статье я продолжу рассказ об использовании Subversion – одной из самых популярных на сегодняшний день систем контроля версий.

В этот раз речь пойдет об использовании нескольких веток разработки.

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

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

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

Как раз в этом случае нам и пригодится возможность Subversion создавать параллельные ветки разработки.
Читать дальше

В прошлой статье мы начали знакомство с одной из самых популярных на сегодняшний день систем управления версиями – Subversion. На данный момент мы создали начальную структуру проекта и поместили ее в хранилище Subversion.

Напомню, для нашего проекта в хранилище создано две папки:
trunk – в ней будет находится основная ветка проекта;
и branches – для экспериментальных веток.

Теперь нужно создать рабочую копию. Для этого переходим в папку, которую будем использовать для работы с проектом, и выполняем команду:
svn checkout file:///e:/docs/svn/my_project/trunk

Обратите внимание, что к пути, указывающему размещение хранилища, мы добавили /trunk. Это означает, что мы создаем рабочую копию основной ветки проекта.

Т.к. на данном этапе проект пуст, то в папке с рабочей копией будет размещена только папка «.svn» (скрытая) со служебными файлами Subversion.

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

Добавляем файл в проект

Допустим, мы создали (в папке с рабочей копией) файл index.php и хотим добавить его в хранилище. Для этого выполняем команды:
svn add index.php
svn commit index.php -m "добавлен новый файл index.php"
Читать дальше

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

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

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

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

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