Субботним вечером в очередном выпуске подкаста Radio-T (http://radio-t.com) ведущие в процессе традиционного флейма о мобильных устройствах и их программных начинках отвлеклись на обсуждение средств разработки, и в разговоре была упомятута система контроля версий Fossil, которая преподносилась простым и высокоинтегрированным средством, пригодым для использования индивидуальным разработчиком. Авторитет ведущих в этой области не вызывает сомнения, поэтому решено было посмотреть на этот продукт по горячим следам.
Считаю необходимым сразу предупредить читателей о том, что в статье будет изложен взгляд индивидуального разработчика, для которого программирование - не более чем хобби, и который до настоящего момента в вопросе версионизации своих работ ограничивался возможностями файловой системы, архиватора и текстового редактора. Так что ожидать здесь инструкций по развёртыванию корпоративных систем контроля версий не стоит. С другой стороны, информация может заинтересовать студентов и небольшие команды программистов, которые начинают новый проект или по каким-то причинам на сегодняшний день не используют таких систем. Итак, начнём.
Словосочетание "система контроля версий" неразрывно связано с такими брендами как CVS, Git и Mercurial, а заодно наводит на мысль об организации, настройке и администрировании серверов, клиентского ПО, и рутинных канцелярских процедурах, отвлекающих от творческого процесса создания программного продукта. Если такая система функционирует, то, по-видимому, это здорово помогает работе, однако запускать её с нуля добровольно не всегда поднимаются руки. Давайте посмотрим, может ли Fossil изменить наши представления о системах контроля версий?
Описание на главной странице проекта обнадёживает. Несмотря на то, что Fossil позиционируется как "распределённая система контроля версий", радует наличие прилагательного "простая". Fossil изначально предусматривает возможность использования на локальной машине, базируясь на СУБД SQLite и имея в своём составе встроенный web-сервер, который позволяет настраивать систему и управлять ею с помощью браузера. Но на этом хорошие новости не заканчиваются. Помимо собственно возможностей по поддержанию истории изменений исходных файлов, Fossil предлагает интегрированную систему багтрекинга (bugtracking) через тикеты (tickets) и систему документирования на основе wiki. Как работает весь этот конгломерат, хорошо иллюстрирует сайт проекта: http://www.fossil-scm.org/ (он полностью функционирует на Fossil).
Если же проект разрастается, то Fossil можно переконфигурировать в сетевой режим работы с распределённым репозиторием. На этот случай имеется возможность работы с "внешним" CGI-сервером (хотя для большинства применений должно хватить сетевого режима работы самого Fossil). А оптимизация протокола сетевого взаимодействия, по заявлению разработчика Fossil, позволяет работать даже через медленные dial-up соединения. И нет причин не доверять его словам, потому что Ричард Хипп является автором другого бестселлера (если такой эпитет допустим в случае свободного программного обеспечения) -- СУБД SQLite. Использование базы данных SQLite в качестве хранилища файлов проекта обеспечивает выполнение атомарных коммитов (atomic commits) и высокую степень защиты от сбоев.
Теперь хорошо бы проверить все эти высказывания на практике. К счастью, нет ничего проще! С точки зрения развёртывания Fossil представляет собой единственный исполняемый файл, реализующий все описанные выше возможности. Большинство команд настройки и управления репозиторием подаются из командной строки.
Скачиваем бинарик для подходящей операционной системы (дальше будем предполагать, что используется Windows) с сайта http://www.fossil-scm.org/download.html и записываем его в каталог, прописанный в переменной путей поиска PATH.
Создаём новый репозиторий для нашего проекта с помощью команды
fossil init D:\REPO\myproject.fossil
Переходим в каталог верхнего уровня дерева каталогов с исходными файлами проекта и создаём ассоциацию между репозиторием и этой структурой каталогов командой
fossil open D:\REPO\myproject.fossil
(при этом в текущем каталоге будет создан файл _FOSSIL_)
В принципе, уже сейчас можно запустить web-интерфейс системы контроля версий и оценить проделанную работу. Для этого служит команда
fossil ui D:\REPO\myproject.fossil
Однако для работы системы по её прямому назначению нужно указать, изменения в каких файлах должны отслеживаться. Для постановки файлов проекта "на учёт" нужно из подкаталога, где размещён файл, выполнить команду
fossil addимя_файла
Когда все файлы будут перечислены, поместить в репозиторий текущее состояние проекта можно командой
fossil commit
(при этом текущим должен быть один из подкаталогов зарегистрированного дерева каталогов проекта).
Такой способ работы выглядит достаточно необременительным, а потенциальная выгода от использования специализированной системы контроля версий велика даже для индивидуального разработчика.
В заключение несколько слов о том, что предлагает Fossil для "серьёзного" применения. Во-первых, поддерживается разветвление (branching) и слияние ветвей проекта (merging). Во вторых, имеется возможность работы с удалёнными репозиториями как в одном направлении (push и pull), так и в обоих (sync). Нужно только не забывать, что изменения из удалённого репозитория при синхронизации попадают в локальный репозиторий, но не в дерево каталогов. Чтобы временной срез проекта распаковать из репозитория в файловую систему дерева каталогов, надо использовать команду
fossil updateверсия
(если не указать версию среза, то будут выгружены последние изменения).
Ну и в-третьих, если после тестирования Fossil у участников проекта возникнет желание перейти на него от используемых CVS или Git, средства Fossil помогут осущетвить портирование репозиториев.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.