Системы контроля версий: Fossil, часть I

Приветствую вас, коллеги!

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

За годы участия в open source разработках мне довелось пользоваться CVS, Subversion и Git, но для личных и связанных с работой проектов системы контроля версий не использовал, пока по случайной ссылке не познакомился с Fossil. Сразу зацепило то, что надо всего лишь скачать и скопировать в подходящее место один — единственный исполняемый файл. Если это так просто, почему бы не попробовать? Понравилось также, что весь репозитарий — это тоже один файл (SQLite база данных), который можно просто скопировать, чтобы забрать домой или установить на другой компьютер на работе. Мне вообще по душе минималистский подход — может, именно поэтому рука не подымалась ставить для коллектива из 3-4 человек или для личного использования что-то типа Subversion.

Как оказалось, Fossil — вполне «взрослая» система, не уступающая по основным функциональным возможностям своим более известным конкурентам. В качестве солидного бонуса мы имеем здесь web-интерфейс, систему отслеживания ошибок (Bug Tracking) и Wiki, причем уведомления об ошибках и wiki-страницы находятся в том же репозитарии, где и файлы проекта и тоже находятся под управлением системы контроля версий, т.е. их изменения также отслеживаются. В процессе эксплуатации и по мере изучения документации выявились еще мелкие, но приятные «вкусности», которые добавили убежденности в правильности сделанного выбора. Сразу хочу подчеркнуть: правильности для меня. У всех разные требования, разные привычки, кому-то больше подойдет что-то другое. Для меня Fossil — вполне подходящее, если не сказать больше, решение.

Установка Fossil
Итак, заходим на http://www.fossil-scm.org/download.html и скачиваем пакет, соответствующий нашей операционной системе. Распаковываем находящийся там исполняемый файл куда-нибудь, откуда потом его будет удобнее запустить, желательно — в каталог, доступный по SET PATH. Все, система готова к работе.

Создание и настройка репозитария
Дальше, для определенности, мы будем исходить из предположения, что у нас стоит Windows. Также, для определенности, будем считать, что все наши репозитарии будут храниться в отдельном каталоге c:fossil, хотя, конечно, можно и не выделять для них какого-то отдельного места, а размещать непосредственно рядом с файлами, которые мы отдаем под управление Fossil. Далее, предположим, что у нас есть проект Castle, исходники которого, находящиеся в c:projectscastlesource, мы хотим поставить под контроль Fossil — мы будем называть их рабочими файлами, а каталог source — рабочим каталогом. И создаем, наконец, для этих исходников пустой репозитарий castle.fossil:

fossil new c:fossilcastle.fossil

Fossil создаст файл castle.fossil и сообщит нам имя администратора ( обычно это имя пользователя, под которым вы вошли в ОС ) и пароль. Fossil вообще довольно «разговорчив» и его сообщения надо читать, там может содержаться важная информация. Как вы уже поняли, все это происходит в консоли, так что для использования Fossil желательно иметь навыки работы с командной строкой, а так же быть знакомым с английским языком — может, я плохо искал, но никаких упоминаний об интернационализации не нашел.
Следующий шаг — переходим в каталог c:projectscastle и открываем созданный репозитарий:

c:
cd projectscastle
fossil open c:fossilcastle.fossil

Большинство операций Fossil производятся над открытым репозитарием, поэтому это следует сделать сразу после создания. А вот закрывать его (fossil close) вряд ли имеет смысл — разве что после завершения проекта. Команда открытия fossil open создает в текущем каталоге служебный файл базы данных, его имя может зависеть от версии Fossil и от ОС — под Windows это _FOSSIL_. В этом файле хранится информация об открытом репозитарии и отслеживаются изменения в файлах. Обратите внимание, что перед тем, как открыть репозитарий, я перешел в каталог, родительский по отношению к рабочему. Это важно: репозитарий должен быть открыт или в рабочем каталоге, или в одном из родительских ( на любом уровне дерева ), иначе Fossil откажется добавлять файлы из рабочего каталога в репозитарий.
Вообще-то fossil open не только создает служебный файл, но и проверяет соответствие между файлами в рабочем каталоге и в репозитарии, и если какой-либо файл из репозитария отсутствует в рабочем каталоге, или отличается от него, то перезаписывает файл в рабочий каталог из репозитария ( после предупреждения all/yes/no ). Но поскольку наш репозитарий пока пуст, ничего такого не происходит.

Перед тем, как добавить файлы в репозитарий, я бы посоветовал кое-что предварительно настроить. Это можно сделать двумя способами.
1) Из консоли при помощи команды fossil settings:

fossil settings crnl-glob '*'
fossil settings encoding-glob '*'

Установка crnl-glob в '*' (любое) отключает проверку символов конца строки, encoding-glob — проверку кодировки ваших файлов. Если это не сделать, а в ваших файлах используется стандартная для Windows последовательность CRNL или кодировка, отличная от UTF-8, то Fossil выдаст предупреждение и будет требовать подтверждения при операции commit. Кроме того, желательно указать список масок файлов, которые могут присутствовать в вашем рабочем каталоге, но не должны быть включены в репозитарий — объектные модули, исполняемые файлы и пр., например:

fossil settings ignore-glob '*.o,*.obj,*.exe,*.bak,*.log'

Можно добавить в команду fossil settings опцию --global — в этом случае данный параметр будет установлен глобально, для всех репозитариев на этом компьютере. Кстати, если устанавливаемое значение не указано, то команда fossil settings вернет в ответ текущее значение параметра, а если и имя параметра не указывать, то мы получим список всех предустановленных параметров и их значения.

2) Второй способ установки параметров — с помощью графического интерфейса:

fossil ui

В результате исполнения этой команды будет запущен встроенный в Fossil web-сервер, в данном случае локальный, ( порт по умолчанию — 8080, можно указать другой опцией --port ) и броузер — на URL 127.0.0.1:8080. Для установки параметров откроем пункт меню admin, потом settings и меняем там crnl-glob, encoding-glob и ignore-glob. Заодно можно зайти в admin / configuration — установить название проекта и в admin / users — поменять свой пароль.

Ну и, наконец, добавляем файлы командой add и отправляем в репозитарий командой commit:

fossil add source
fossil commit -m "Initial commit"

Add может добавлять как отдельные файлы, так и каталоги, можно использовать и маску файлов. Команда

fossil add .

добавляет все файлы из текущего каталога и подкаталоги.

Теперь, когда репозитарий открыт и файлы в него добавлены, т.е., поставлены под управление Fossil, можно, собственно, продолжить работу над проектом. Пишем программы, статьи, книги, при каждом важном изменении отправляем его в репозитарий — делаем commit, сопровождая его осмысленным комментарием:

fossil commit -m "Another brick in the wall"

Вот еще несколько команд для удаления/перемещения/добавления файлов:

fossil rm sourcewallbrick.c

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

fossil mv sourcebridgeitem* sourcewall

Перемещаем файлы с маской item* из одного каталога в другой. Учтите, что Fossil сам не перемещает файлы в рабочем каталоге, нам надо сделать это руками.

fossil addremove

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

И несколько команд, предоставляющих информацию о репозитарии и отдельных файлах:

fossil ls sourcewall

Выводим список файлов из каталога sourcewall, находящихся в репозитарии, параметр -v добавляет колонку с состоянием файла (EDITED, UNCHANGED), параметр --age — время последнего commit для каждого файла.

fossil status

Смотрим текущее состояние репозитария.

fossil changes

Выводим список файлов, измененных со времени последнего commit.

fossil extras

Выводим список «лишних» файлов — тех, что присутствуют в рабочем каталоге, но не включены в репозитарий.

Команды для работы с версиями файлов — просмотр изменений, возврат

fossil timeline
fossil timeline after 2014-09-01
fossil timeline before 2014-07-15

Выводим историю изменений репозитария, параметр -v добавляет в вывод список файлов, затронутых каждым изменением. С помощью -t можно указать, какого рода изменения следует выводить: -t ci — в файлах, -t e — в событиях, -t t — в tickets, -t w — в wiki.

fossil finfo sourcewallbrick.c

По умолчанию — выводим историю изменений файла brick.c. Если задан параметр -s — то краткую информацию о файле, если -p — выводится содержимое файла, а если вдобавок к -p задан еще и идентификатор версии ( -r VERSION ), то выводится заданная версия файла.

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

• SHA-1 хэш
• имя метки (tag)
• timestamp — дата и время создания
• выделенные имена: tip, current, next, previous или prev

Каждый элемент в репозитарии Fossil — и версии файлов, и tickets, и wiki-страницы и пр. — имеют уникальный идентификатор, 40-значный хэш, вычисленный по SHA-1. Поскольку вводить все 40 знаков в команде не очень удобно, можно ограничиться несколькими ( не менее 4 ) первыми его знаками. Итак, первый способ идентификации версии файла — начальный фрагмент хэша. Другой способ — дата и время создания файла записанное в одном из форматов: YYYY-MM-DD, YYYY-MM-DD HH:MM, YYYY-MM-DD HH:MM:SS. Подробнее смотрите здесь.

fossil diff sourcewallbrick.c
fossil diff --from VERSION1 --to VERSION2 sourcewallbrick.c
fossil diff --from previous --to current sourcewallbrick.c

Выводим в консоль разницу (diff) между разными версиями указанного файла. Здесь VERSION1 и VERSION2 — идентификаторы версий, в соответствии с описанием, приведенным чуть выше — к команде fossil finfo. Если они не указаны, то выводится разница между последней версией из репозитария и файлом в рабочем каталоге. Если установлен Tcl/Tk ( он обычно стоит в Linux-системах, но есть порт и для Windows ), то можно воспользоваться опцией -tk — в этом случае для показа отличий будут использованы встроеннные графические средства, основанные на Tcl/Tk. Если у вас есть GUI программа для графического представления разницы между текстовыми файлами ( я в Windows использую examdiff.exe ), то можно предварительно установить ее в качестве значения параметра Fossil diff-command с помощью web-интерфейса или команды fossil settings diff-command — тогда эта программа будет вызываться при выполнении fossil diff.

fossil gdiff

То же, что fossil diff, только для вывода отличий используется программа, прописанная как значение параметра Fossil gdiff-command.

fossil tag add TAGNAME VERSION
fossil tag cancel TAGNAME VERSION

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

fossil revert
fossil revert sourcewallbrick.c
fossil revert -r VERSION sourcewallbrick.c

Возвращаем в рабочий каталог заданную версию файла ( или все файлы, если имя файла не указано ). Если версия (-r VERSION) не указана, то берется последняя — та, что попала в репозитарий во время последнего commit. Идентификатор версии указывается в соответствии с правилами, описанными выше ( к команде fossil finfo ).

fossil undo

Отменяем изменения в рабочем каталоге, сделанные командой revert, merge или update ( две последние мы будем рассматривать позже, во второй части ).

Ну и, конечно, help — как же без нее:

fossil help
fossil help add

Help без аргументов выводит список команд, а с названием команды в качестве аргумента ( например, add, как в примере ) — описание этой команды.

Не могу удержаться, чтобы не рассказать еще об одной команде — fossil all. Она производит указанное действие со всеми открытыми репозитариями:

fossil all list
fossil all changes
fossil all extras
fossil all pull
fossil all push
fossil all sync

list — выводит список репозитариев, changes — список измененных файлов во всех репозитариях и т.д.

Web-интерфейс, tickets, wiki
Я уже упоминал о web-интерфейсе Fossil, запускаемом командой fossil ui, когда рассказывал о настройке репозитария. Выглядит это примерно так:

Кроме просмотра и изменения настроек (Admin) здесь можно посмотреть историю проекта (Timeline), список файлов (Files) и каждый файл в отдельности, структуру веток проекта (Branches), метки (Tags), поработать с Bug Tracking системой (Tickets) и с Wiki — документацией.

Просматривая историю (Timeline), вы можете выбрать любую версию, щелкнув по ее идентификатору ( хэш-код в квадратных скобках ), а там — посмотреть спиок файлов на тот момент, список измененных файлов, отличия от предыдущей версии для каждого файла ( щелкнув по [diff] ), можете скачать zip- или tar- архив этой версии, отредактировать ее представление в истории, в т.ч. подкрасить, и т.д.

Хотел бы вкратце остановиться еще на использовании Tickets и Wiki. Tickets — в данном случае это слово, наверное, будет правильно перевести как «карточки» — способ реализации системы отслеживания ошибок, Bug Tracking, хотя эти карточки, вообще говоря, можно использовать не только для сообщений об ошибках, но и для планирования работы над проектом. Итак, выбираем Tickets, далее — New ticket и заполняем карточку — краткое содержание, тип, номер версии, к которой относится эта запись, степень критичности, email и подробное описание, в котором можно использовать wiki-разметку, а значит, ссылаться на любые объекты в репозитарии по их идентификатору — другие карточки, wiki-страницы, версии файлов. Кстати, эта возможность использования идентификаторов как ссылок представляется мне очень ценной, поскольку она повышает связность информации в репозитарии, способствует максимальной интеграции всех частей проекта. Будучи введенным, Ticket появляется и в списке All tickets, и в Timeline. Его теперь можно открыть, добавить дополнительные замечания, наложить резолюцию ( fixed, rejected, Unable_To_Reproduce, Works_As_Designed, и др. ). Если ticket закрыт, то при commit соответствующего исправления желательно указать в квадратных скобках идентификатор этой карточки, тогда в истории версий в соответствующей строчке будет ссылка на ticket.

Перед тем, как начать пользоваться Wiki, желательно указать название проекта, если это еще не сделано: Admin / Configuration — заполняем поле Project Name и жмем кнопку Apply Changes. Выбираем Wiki, жмем на Castle project home page ( мы назвали проект Castle ) и редактируем эту страницу. Правила используемой wiki-разметки смотрим в Formatting Rules. Пользуемся Preview Your Changes, для сохранения жмем Apply These Changes. Если все нормально, то созданный текст должен появиться на главной странице (Home) под строчкой меню. Напомню, что изменения в wiki-страницах фиксируются системой контроля версий и появляются в Timeline.
Помимо обычных именованных Fossil позволяет создавать wiki-страницы, привязанные ко времени, они называтся events (события) и появляются в Timeline. Создать такое событие можно, выбрав Wiki и, далее, Create a new event. Вводим время, к которому привязываем событие, Timeline Comment — строчку для Timeline, выбираем цвет и редактируем Page Content — т.е., собственно, содержимое страницы. В документации Fossil рекомендуется использовать events как

• Вехи проекта (Milestones) — например, основные релизы
• Записи в блоге разработчиков, описывающие текущее состояние проекта, дорожные карты дальнейшего развития
• Контрольные точки проекта
• Новости, имеющие отношение к проекту
• Объявления.

Заключение
Итак, в первой части обзора было рассмотрено использование Fossil в однопользовательском режиме на одном рабочем месте. Мы научились создавать репозитарий,

fossil new c:fossilcastle.fossil

открывать, настраивать и пополнять его,

c:
cd projectscastle
fossil open c:fossilcastle.fossil

fossil settings crnl-glob '*'
fossil settings encoding-glob '*'
fossil settings ignore-glob '*.o,*.obj,*.exe,*.bak,*.log'

fossil add source
fossil commit -m "Initial commit"

использовать консольные команды и web-интерфейс Fossil в работе над проектом.

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

Автор: alkresin

Источник