Fossil - контроль версий, баг-трекер и wiki в одном флаконе

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

Лично я люблю git для UNIX и mercurial для Windows. Каждая система имеет пачку удобных хостингов, как говорится, выбирай на вкус.

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

Начал я его вести в mercurial, но когда начал утопать в письмах и документации, то осознал необходимость баг-трекера и wiki. Настраивать все это локально (на публичные готовые хостинги выложить не могу) как-то лень. И тут я вспомнил по fossil.

Fossil - это распределенный контроль версий, баг-трекер и wiki в одном флаконе. Более того, его автор -- ни кто иной, как автор SQLite, борец за минимализм, простоту и надежность. Как и в случае с небезызвестной базой данных, которую кто уже только не использует, все, что вам нужно - это один единственный файл -- fossil[.exe].

Для командной строки - это просто SCM, а будучи запущенной с параметром "ui", превращается в локальный веб-сервер, в котором есть "морда" для просмотра репозитория, баг-трекера и wiki. Более того, все данные живут также в одном единственном файле-репозитории, который по сути является SQLite-базой. Для переноса его в другое место, другую операционную систему или резервного копирования, нужно просто скопировать один файл.

fossil умеет импортировать и экспортировать в git, поэтому я сначала перегнал существующий репозиторий из mercurial в git, а потом импортировал из git в fossil.

В целом, fossil хорош. Вылизанный и минималистичный. Говорят, что из-за использования SQLite в качестве хранилища, с одной стороны получаешь надежность и транзакционность любых изменений (понятно, что хоть остальные системы работают просто с файлами, у них с целостностью тоже все в порядке), но с другой стороны, по скорости может радикально проигрывать git или mercurial на больших проектах. Но для небольших "домашних", но секретных проектов - сложно представить удобнее утилиты.

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

Да, лицензия у fossil, конечно, BSD.

Итак, для дома для семьи -- очень удобно.

Архитектура Mercurial на Google Code

После Google I/O Mercurial стал доступен на Google Code в публичном доступе наравне с Subversion.

Весьма занимательное видео, рассказывающее некоторые подробности о внедрении Mercurial на Google Code. Почему именно Mercurial, а не Git или Bazaar, какие особенности именно у Mercurial, отличающие от конкурентов (я, например, не знал, в Mercurial хеш-идентификатор каждого коммита задействует не только метаданные, но и само содержимое файлов, что конкретно ограничивает возможности "переписывания" истории, хотя с точки зрения гугловцев это преимущество, нежели недостаток), и, собственно, как все это легло в инфраструктуру Google.




Посты по теме:

• Какую распределенную систему контроля версий выбрать: Git, Bazaar или Mercurial?

Какую распределенную систему контроля версий выбрать: Git, Bazaar или Mercurial?

Последние две недели занимаюсь вялотекущим сравнением трех распределенных систем контроля версий: Git, Bazaar и Mercurial.

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

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

С Bazaar познакомился благодаря отличному блогу "Базарный день".

Mercurial пришлось попробовать, так как это православно (причем весьма заслуженно).

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

О колокольне, с которой я смотрю на предмет. Я ищу систему не для дома (собственные проекты у меня сидят на разных системах, и все нормально), а для поддержки системы на нескольких видах UNIX плюс еще и Windows. Примерное количество файлов в ветке проекта около шести тысяч. Объем ~250 мегов (увы, есть некоторое количество двоичных файлов). Объем репозитория особо не волнует, если речь идет о разумных цифрах.

Git

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

Теперь по делу.

Что мне очень нравится в Git — это наличие staging системы (промежуточное звено между рабочими файлами и репозиторием). Очень удобно, когда можно подготовить для комита не весь файл, а только его часть.

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

Очень подкупает невообразимо мощная команда rebase, которой можно сделать с историей проекта все (в том числе и испортить). То есть Git не возводит в религию неприкосновенность истории. Механизм для ее модификации дается, но вот ответственность за результат перекладывается на пользователя. Никто не запретит тебе простым ключиком "--amend" подправить синтаксическую ошибку в тексте последнего комита (да и любого другого комита) или удалить любой комит из истории, но вот надо тебе или нет — вопрос персонального подхода к работе. Из личного опыта как занимающего выпуском релизов скажу, что порой очень нужно иметь возможность менять историю, увы. В Perforce мне из-за этого приходится делать много ручной работы.

Под занавес — есть приятный бонус в виде качественного публичного хостинга github.com.

Из минусов, трогающих меня — это просто омерзительный порт под Windows. Я пользуюсь версией, построенной на MinGW. Пока непобежденным глюком для меня является тот факт, что по какой-то причине некоторые базовые утилиты UNIX, входящие в состав дистрибутива Git под Windows, при старте пытаются, видимо, определить наличие всех логических дисков (C:, D: и т.д.) в системе. Хорошо, когда нет сетевых дисков, а вот когда они есть, то такой опрос занимает раздражающие 2-3 секунды при каждом запуске (причина была выявлена путем анализа сетевого трафика, так как сначала я думал, что у меня вирус). На домашнем компьютере все отлично — там нет сетевых дисков.

Но несмотря на все препоны, с помощью git-p4 я наладил для некоторых наших разработчиков, работающих часто в офлайне, неплохой механизм интеграции с централизованным Perforce. Человек синхронизируется, будучи онлайн, и обновляет локальный репозиторий Git. Потом спокойно работает в офлайне через Git, а затем опять в онлайне засылает все сделанное из Git в Perforce.

Bazaar

Классная система. Работает с полоборота из коробки, но только там, где есть Питон, поэтому на некоторых наших вынужденных UNIXах меня ждал облом.

Пока я не нашел особых смысловых изъянов, мешающих мне работать.

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

Как-то с ходу не нашел бесплатного хостинга для Bazaar.

Mercurial

Снова Питон, поэтому автоматически все шоколадно на системах, где он есть, но грустно, где его нет.

Из хороших бонусов есть факт, что Google сделал поддержку хостинга для этой системы. Как написано в их отчете о том, почему они выбрали именно Mercurial, а не Git, как я понял, говорится, что основные причины в более простой интеграции Mercurial в систему http-сервисов (Git тоже умеет через http, но медленнее), и логическая близость синтаксиса команд Mercurial к Subversion (тут, конечно, Git ой как далеко).

В целом, для себя я решил пока так: если для дома для семьи или там где Windows да Linux, то это без сомнения Bazaar или Mercurial (можно монетку подкинуть), а вот все-таки для применения на множестве разнородных систем и там где надо уметь управлять историей, то пока Git.

Travis Swicegood, "Pragmatic Version Control using Git"

Travis Swicegood

Pragmatic Version Control using Git



Хорошее введение в распределенную систему контроля версий Git от сообщества разработчиков ядра Линукса и от Линуса Торвальдса в частности.

Я ценю такие книги за начальное вовлечение в предмет. Это книга для начинающих, и если вы не новичок в области распределенных систем контроля версий, то вы ее проглотите за вечер и захотите более глубоких знаний по Git. Так и произошло со мной. Я прочитал книгу за вечер, она сформулировала в голове десятки неотвеченных вопросов и позволила мне понять — на какие вопросы мне нужны ответы.

На официальном сайте есть превосходная электронная живая книга по Git. Многие главы имеют дельные коротенькие видео уроки.

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

P.S. Для интересующихся распределенными системами контроля версий рекомендую отличный блог про альтернативую систему Bazaar "Базарный день". Прочтете несколько постов и будете готовы использовать Bazaar.