Назад в мезозой к программным динозаврам вместе с системой контроля версий Fossil

Несмотря на обилие существующих систем управления версиями (Version control systems), сквозь асфальт устоявшихся DVCS пробиваются время от времени новые и свежие поделки попытки. DVCS всё пилят и пилят, а серебряной пули как не было, так и нет: у одной системы - бинарные патчи, у другой - нет симметричного push, третья написана на питоне, и, хотя это наименьшее из зол, проблемы из-за наличия другой версии питона не радуют.

Но вот сравнительно недавно появившийся Fossil уже несколько возмужал и окреп, и для некоторых не особо больших и важных проектов, кажется, уже годен для использования.
Сейчас мы этим Fossil и займёмся.


Почему Fossil?
Потому, что он имеет несколько killer-features, которых нет у конкурентов:

• все данные хранятся в одном файле, который представляет собой SQLite базу данных, так что файлы не повредятся, если кто-то перенесёт данные на флешке с FAT;
• написан на канонiчном C и представляет собой один-единственный экзешникисполнимый файл;
• wiki, ticket system и графический интерфейс в одном флаконе (здесь привет всем сразу);
• нормальный, человеческий симметричный push и pull (авторам git на этом месте предлагается удавиться);
• имеет адекватную документацию и в меру человеческий интерфейс;
• атомарные коммиты и параноидальная проверка целостности данных перед коммитом.

В общем, это то, о чём так долго мечтали белые, красные, зелёные, и даже голубые! Более того, если у вас есть опыт работы с SVN или Mercurial, вы почувствуете себя почти что дома - только некоторые приёмы работы будут вас, скажем так, удивлять. Но и это в большинстве своём настраивается по вкусу.

Установка Fossil
Установить Fossil очень просто: идём на сайт программы, выбираем сборку для своей операционной системы, и скачиваем единственный исполнимый файл.

Далее распаковываем архив, получаем файл fossil
Копируем этот файл по вкусу, например в /usr/local/bin и всё, Fossil готов к работе.




Начало работы с Fossil
Fossil использует файл-репозиторий, который является базой данных SQLite, для хранения всех файлов и истории проекта внутри.

Создание репозитория
Для начала работы можно создать новый репозиторий:

fossil init mygtd.foss

или клонировать существующий:

fossil clone /mnt/flash/exthdd/data/mygtd.foss

Далее нам нужно открыть репозиторий - сделать check-out и заполучить локальные файлы для работы:

fossil open mygtd.foss

При этом в текущую директорию будут извлечены все файлы из базы данных и появится файл _FOSSIL_ В нём содержится, помимо прочего, то, что вы можете отменить, список переименованных файлов и расположение репозитория. Изменения, которые не были отправлены в репозиторий (commit) тоже отслеживаются в файле _FOSSIL_ поэтому если вы что-то изменили в файлах и пытаетесь закрыть репозиторий командой

fossil close mygtd.foss

то получите сообщение:

fossil: there are unsaved changes in the current checkout

Это напоминание о том, что надо сделать коммит.


Отправка изменений (commit) в репозиторий Fossil
Каждое важное изменение файлов следует отправлять в репозиторий, снабдив осмысленным комментарием:

fossil ci -m "added new ideas from Brainstorm"

и через некоторое время, после всех проверок коммита, получим сообщение:

New_Version: a17e00ea83545549fb542a6fb6916b28fda66c15

Здесь нужно заметить, что коммиты Fossil завязаны на текущее время, и он крайне не любит (в отличие от, скажем, HG), если часы показывают неправильное время:

fossil ci -m "minor"

выдаст предупреждение:

fs: ancestor check-in [f29b4f1ee8] (2012-02-28 01:20:15.195) is not older (clock skew?) Use -f to override.

То есть часы стоит синхронизировать хотя бы иногда.

И ещё, если что-то в исходниках изменится за время коммита (например, сработает автосохранение в текстовом редакторе для файла, который есть в репозитории), то Fossil откажется коммиттить с формулировкой:

fossil ci -m "WeeklyReview - adding new projects"
New_Version: ef74d0458c158277dd12213c2d675ad7397d84ed
fs: working checkout before and after commit does not match

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

 


Ускорение коммитов в Fossil
Коммиты в Fossil делаются по умолчанию очень долго по сравнению с Git/Hg/Subversion, из-за того, что выполняется очень много проверок. Это делается для того, чтобы была полная уверенность в целостности файлов в репозитории:

In addition to identifying all files in the check-in, a manifest also contains a check-in comment, the date and time when the check-in was established, who created the check-in, and links to other check-ins from which the current check-in is derived. There is also a couple of checksums used to verify the integrity of the check-in. And the whole manifest might be PGP clearsigned.[документация]

Это можно настроить с помощью параметра repo-cksum. По умолчанию эта опция включена ("on") и приводит к вычислению контрольной суммы по всем файлам при каждом коммите как двойная проверка правильности. Команда

fossil settings repo-cksum off

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

Коммиты и окончания строк в Fossil
Если вы работаете в коллективе, где используются Windows/MacOS, вы можете получать при коммитах сообщения вида:

./Projects/Project-EmailsToWrite.tex contains CR/NL line endings; commit anyhow (yes/no/all)?all

Это не ошибка, а предупреждение. Дело в том, что в Windows в качестве признака конца строки используется комбинация CRNL, а в Unix - просто NL. При переносе файлов между разнородными системами могут возникать как просто неудобства (текст с NL в Windows "вытянется" в одну строчку, а заметка с CRNL в Unix будет содержать "мусор" в конце каждой строки), так и реальные проблемы (в Unix не будут работать скрипты с CRNL).

Если вы не хотите видеть такие предупреждения, их можно отключить в командной строке:

fossil settings crnl-glob '*'

или в графическом интерфейсе:

fossil ui

Далее идём в секцию admin, потом в settings. Ищем и находим опцию "crnl-glob", и ставим в поле звёздочку: *. Это позволит игнорировать все окончания строк в формате CR/NL.


Коммиты и автоматическая синхронизация в Fossil
Есть у нас, к примеру, удалённый репозиторий, с которым мы хотим синхронизовать свой текущий репозиторий или послать туда изменения. Таковым станет репозиторий, в который мы в последний раз отправляли или запрашивали изменения.

Проблема в том, что по умолчанию автоматическая синхронизация включена, и это попортит начинающему массу нервов. Fossil на коммите думает, что если вы что-то пнули (push) в другой репозиторий (например, на резервном харде) - всё, с ним надо синхронизоваться до конца жизни. Если удалённый репозиторий недоступен, то не только не получится синхронизоваться, но и, собственно, закоммитить изменения в локальный репозиторий:

fossil ci -m "erase unnecessary phonebooks"

получим:

Autosync: file:///mnt/flash/mmc/mygtd/mygtd
Bytes Cards Artifacts Deltas
Sent: 130 1 0 0
fs: server sends error: >repository does not exist or is in an unreadable directory: /mnt/flash/mmc/mygtd/mygtd>

Более того, синхронизация тоже обломится:

fossil sync mygtd
Bytes Cards Artifacts Deltas
Sent: 3575 75 0 0
Error: Database error: database is locked
UPDATE event SET mtime=(SELECT m1 FROM time_fudge WHERE mid=objid) WHERE objid IN (SELECT mid FROM time_fudge);DROP TABLE time_fudge;
Received: 197 1 0 0
Total network traffic: 2068 bytes sent, 347 bytes received

Как говорилось в одном анекдоте, слющий абыдна да? Но всё можно поправить лёгким и непринуждённым движением:

fossil setting autosync off

Не знаю, кому в голову пришло это ставить по умолчанию on, но этот кто-то делает такое зря.



Добавление, перемещение и удаление файлов в Fossil
Собственно, добавление файлов просто и логично:

fossil add References/Personal/*.text

и теперь они добавлены:

ADDED References/Personal/Link.text
ADDED References/Personal/LinkScience.text

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

$ fossil extras

И вот что мы видим:

Brainstorm.tex~
Projects/Project-MyOrgSys-Fossil.tex.backup
Projects/Project-MyOrgSys-Fossil.tex~
Projects/actionsProject-SplinePlay.tex~
References/Personal/Link.text
References/Personal/Link.text~
References/Personal/LinkScience.text
References/Personal/LinkScience.text~
mygtd-2706199415843815819-in.http
mygtd-2706199415843815819-out.http
mygtd-shm
mygtd-wal

Красным помечены файлы, которых в репозитории нет, а в каталоге есть.


Перемещение файлов в Fossil
... реализовано немного заковыристо. Например:

fossil mv Projects/DONE/*AORTA*DM* Projects/

получаем:

RENAME Projects/DONE/Project-AORTADM.tex Projects/Project-AORTADM.tex
RENAME Projects/DONE/actionsProject-AORTADM.tex Projects/actionsProject-AORTADM.tex

и смотрим на статус репозитория - что случилось?

fossil status

repository: /home/latitude/docs/mygtd/mygtd
local-root: /home/latitude/docs/mygtd/
checkout: a17e00ea83545549fb542a6fb6916b28fda66c15 2012-02-16 23:09:39 UTC
parent: 323b6e0da110298f7754032845cd43c5a1e7c2c6 2012-02-16 11:13:33 UTC
tags: trunk
comment: new ideas from Brainstorm (user: beast)
EDITED Brainstorm.tex
MISSING Projects/Project-AORTADM.tex
EDITED Projects/Project-Blog-ZapiskiDebianshika.tex
EDITED Projects/Project-EmailsToWrite.tex
MISSING Projects/actionsProject-AORTADM.tex
EDITED Projects/actionsProject-DMmodelsReview.tex

Часть файлов "пропали" - и если попробовать закоммитить изменения:

fossil ci -m "adding more projects"

получим ошибку:

fossil: no such file: /home/latitude/docs/mygtd/Projects/Project-AORTADM.tex

А файлов-то и нет, вернее, репозиторий об этом не знает. Проблему решает обновление:

fossil update

и теперь:

latitude@dot:~/docs/mygtd$ fs up
UPDATE Projects/Project-AORTADM.tex
UPDATE Projects/actionsProject-AORTADM.tex
--------------
updated-to: a17e00ea83545549fb542a6fb6916b28fda66c15 2012-02-16 23:09:39 UTC
tags: trunk
comment: new ideas from Brainstorm (user: beast)
"fossil undo" is available to undo changes to the working checkout.

Всё, теперь файлы перемещены.


Перемещение файлов в Fossil: если в директории такой файл уже есть...
то пользователя ждёт сюрприз: затирать файлы, как Hg, Fossil не станет, даже если поставить ключ -force:

fossil mv -force Projects/*Alexandria* Projects/DONE/

на это мы получим маловразумительное:

RENAME Projects/Project-Alexandria.tex Projects/DONE/Project-Alexandria.tex
fs: SQLITE_CONSTRAINT: abort at 34 in [UPDATE vfile SET pathname='Projects/DONE/Project-Alexandria.tex' WHERE pathname='Projects/Project-Alexandria.tex' AND vid=1815]: columns pathname, vid are not unique
fs: columns pathname, vid are not unique
UPDATE vfile SET pathname='Projects/DONE/Project-Alexandria.tex' WHERE pathname='Projects/Project-Alexandria.tex' AND vid=1815

If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.

Вообще, отвлекаясь от темы: сообщения об ошибках Fossil это цирк с конями. Иногда кажется, что несколько марсиан из команды инопланетных захватчиков Git затесалось-таки в разработчики Fossil.

На самом деле это сообщение означает, что Fossil так не даёт затереть файлы, которые уже есть в другой директории. То есть если мы перемещаем файлы в другую директорию, а они там уже есть, нам выведут вот такое сообщение. Вариантом решения проблемы является предварительное затирание:

fs rm Projects/DONE/*Alexandria*

имеющегося файла, обновление:

fossil update

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



Отправка (push) и запрос (pull) изменений в удалённые репозитории Fossil
Вот тут-то как раз всё очень просто: Fossil, в отличие от всяких git-ов, делает как раз то, что вы от него ждёте.

Запрос изменений из удалённого репозитория (pull)
Чтобы скачать изменения из удалённого репозитория, достаточно написать:

fossil pull

и мы получим:

Server: file:///mnt/flash/exthdd/fossil/mygtd
Bytes Cards Artifacts Deltas
Sent: 146 2 0 0
Received: 308 7 0 0
Total network traffic: 288 bytes sent, 410 bytes received

В данном случае изменений нет (подсвечено зелёным), но если бы они были (подсвечено красным):

Server: file:///mnt/flash/exthdd/fossil/mygtd
Bytes Cards Artifacts Deltas
Sent: 7914 9 1 4
Received: 308 7 0 0
Total network traffic: 4684 bytes sent, 411 bytes received

то надо обновить дерево исходников, чтобы их увидеть:

fossil update

Если удалённый репозиторий теперь в другом каталоге, придётся написать полный путь:

fossil pull /mnt/flash/exthdd/fossil/mygtd

чтобы получить изменения из репозитория /mnt/flash/exthdd/fossil/mygtd и после этого не забыть сделать fossil update.

Отправка изменений в удалённый репозиторий (push)
Как все нормальные люди привыкли, в Fossil имеется симметричный push, то есть возможность задудонить изменения в удалённый репозиторий, если на то хватает прав:

fossil push

и изменения будут отправлены в удалённый репозиторий:

Server: file:///mnt/flash/exthdd/fossil/mygtd
Bytes Cards Artifacts Deltas
Sent: 19013 13 2 4
Received: 32 1 0 0
Total network traffic: 7346 bytes sent, 244 bytes received

Всё, теперь удалённый репозиторий имеет те же изменения, что и у вас. На том конце следует сделать update и можно продолжать работать.

Но не всё так сказочно, и бывает, что мы пытаемся сделать push в репозиторий, в который у нас нет прав это делать. То есть права доступа там, скажем, только на чтение, и попытка пнуть (push) туда изменения:

fossil push /mnt/flash/exthdd/zips/mygtd_fossil/mygtd

будет неудачной:

Bytes Cards Artifacts Deltas
Sent: 176 2 0 0
fs: server sends error: >SQLITE_CANTOPEN: cannot open file at line 29653 of [54cc119811]>>SQLITE_CANTOPEN: os_unix.c:29653: (2) open(/mnt/flash/exthdd/zips/mygtd_fossil/mygtd-wal) - No such file or directory>>SQLITE_CANTOPEN: unable to open database file>>Database Error>
>unable to open database file
SELECT value FROM config WHERE name='allow-symlinks'>>If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
>

Это вот так логично у fossil выглядит сообщение о том, что отправка изменений не удалась из-за отсутствия полномочий:

beast@notebeast:/mnt/flash/exthdd/zips/mygtd_fossil$ ls -l
итого 2136
-rw-r--r-- 1 1001 users 2183168 2012-02-13 17:49 mygtd

Не очень понятно, зачем Fossil закатывает такую истерику. Достаточно дать прав командой

chmod 777 /mnt/flash/exthdd/zips/mygtd_fossil

и всё проходит отлично.


Объединение изменений (merge) в Fossil
Если в удалённом репозитории и в вашей рабочей копии произошли изменения в одном и том же файле, или вы добавили какой-то файл локально, то вам предстоит объединение (merge). Процедура эта, как правило, не очень сложная, и таких лютых проблем как в Subversion (10 человек изменили 100 строк в одном файле, и посреди этого праздника его кто-то переименовал) не будет. Вместо этого будет создана новая ветка, и ей присвоен свой хэш. Например:

fossil merge b67775a562

имеем:

ADDED Projects/Project-UniGetIt.tex
ADDED Projects/actionsProject-Alexandria.tex
ADDED Projects/actionsProject-UniGetIt.tex
UPDATE 4myGTD.tex
UPDATE Brainstorm.tex
UPDATE List-Sometimes-Projects.tex
UPDATE Projects/Project-Alexandria.tex
UPDATE Projects/Project-Blog-ZapiskiDebianshika.tex
UPDATE Projects/Project-MediCare.tex
UPDATE Projects/Project-MyOrgSys-Fossil.tex
"fossil undo" is available to undo changes to the working checkout.

И всё, можно продолжать работу.



Удаление лишних файлов в Fossil
Иногда вы создаёте файлы в проекте и забываете их добавить в репозиторий - как проверить, какие файлы добавлены, а какие нет? В Mercurial, к примеру, это видно по команде hg status
У Fossil в этом отношении дело обстоит иначе: fossil status покажет только состояние файлов, которые уже есть в репозитории:

fossil status

и мы можем выяснить, какие файлы изменились (подсвечено зелёным):

repository: /home/beast/docs/mygtd/mygtd
local-root: /home/beast/docs/mygtd/
checkout: d22284b55e52d33ea1e0030a6aebb88523e10ea5 2012-02-19 08:59:01 UTC
parent: f37c24eb6611356c75f14cc64c2d20b5941cf6da 2012-02-19 08:30:55 UTC
tags: trunk
comment: writing post further (user: beast)
EDITED Projects/Project-MyOrgSys-Fossil.tex
EDITED Projects/actionsProject-MyOrgSys-Fossil.tex
EDITED Projects/actionsProject-MyOrgSys-Pomodoro.tex

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

fossil extras

и теперь мы видим:

Brainstorm.tex~
Projects/Project-MyOrgSys-Fossil.tex.backup
Projects/Project-MyOrgSys-Fossil.tex~
Projects/actionsProject-SplinePlay.tex~
References/Personal/Link.text~
References/Personal/LinkScience.text~
mygtd-2706199415843815819-in.http
mygtd-2706199415843815819-out.http
mygtd-shm
mygtd-wal

Всё сплошь бекапы и лишние файлы, как бы их удалить все разом? На этот счёт у Fossil есть замечательная команда

fossil clean --force

Ключ force удалит все лишние файлы, не задавая никаких вопросов при этом.


Графический интерфейс: ticket system, Wiki и другие удобства
Собственно, это одна из главных возможностей (killer-feature). При этом нам не нужно подымать apache и прочую тяжёлую артиллерию - всё уже встроено в сам fossil. Всё, что нам потребуется - это броузер, в котором удобно просматривать сообщения об ошибках (Tickets), историю проекта (Timeline) и Wiki. Например, по команде

fossil ui

мы попадём на главную страницу проекта, которая может выглядеть вот так скромно:

Здесь же есть доступ к истории проекта (Timeline), списку файлов и возможности их просмотреть (Files), веткам кода (Branches), меткам (Tags), системе контроля ошибок (Bugtracking здесь называется Tickets), документации в виде Wiki (Wiki) и настройкам (Admin).

Графический интрефейс очень прост и быстро осваивается. Вот, например, как выглядит история коммитов в графическом интерфейсе:

Кроме этого, есть очень удобная система Tickets. То есть когда в коде проекта появляются ошибки, обычно пользуются сторонними сервисами (Trac или системой контроля ошибок на bitbucket). В случае с Trac это ещё одна программа, которую нужно устанавливать и конфигурировать. Сторонний сервис bitbucket может отвалиться без предупреждений. А в Fossil у вас всегда будет локальная копия, с которой можно работать всегда. Вот как выглядит типичное заведение Ticket:

Добавляем описание, степень критичности бага:

и всё, даём целительный пендаль автору:

Кроме того, есть ещё Wiki, которая тоже содержится прямо внутри проекта, а не на сторонних сервисах. Но для одного поста это уже, пожалуй, многовато.




Недостатки Fossil
Серебряной пули среди систем контроля версий нет, но с Fossil увеличивается надежда, что оная пуля таки появится. Конечно, проект молодой, и разработчики иногда действуют в ковбойском стиле "до основанья а затем". Пока что из минусов Fossil можно упомянуть:

1. Очень медленная синхронизация репозиториев и коммитов.
2. Слишком много мер предосторожности, и, как следствие, очень долгие коммиты.
3. Дурные на всю голову сообщения об ошибках.
4. Довольно топорная работа с ветками. Если вы создали Leaf и там что-то удалили, закрытие Leaf выйдет вам боком.

Но учитывая преимущества Fossil в виде графической веб-морды, баг-трекера и вики в одном флаконе с системой контроля версий, вариант с Fossil смотрится очень даже выигрышно.


Дополнительная информация и ссылки
Fossil Version Control A Users Guide

www.fossil-scm.org/schimpf-book/doc/tip/fossilbook.pdf

File Format: PDF/Adobe Acrobat - Quick View