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

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

Относительно недавно здесь публиковался опрос по используемым системам контроля версий. Как и ожидалось, с большим отрывом победил 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:\projects\castle\source\, мы хотим поставить под контроль Fossil — мы будем называть их рабочими файлами, а каталог source — рабочим каталогом. И создаем, наконец, для этих исходников пустой репозиторий castle.fossil:

fossil new c:\fossil\castle.fossil

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

c:
cd \projects\castle
fossil open c:\fossil\castle.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 source\wall\brick.c
Удаляем brick.c из репозитория. При этом все предыдущие версии этого файла в репозитории остаются, он просто помечается как удаленный и его дальнейшие изменения в репозитории не фиксируются. Из рабочего каталога этот файл не удаляется — если необходимо, мы должны это сделать сами.

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

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

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

fossil ls source\wall
Выводим список файлов из каталога source\wall, находящихся в репозитории, параметр -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 source\wall\brick.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 source\wall\brick.c
fossil diff --from VERSION1 --to VERSION2 source\wall\brick.c
fossil diff --from previous --to current source\wall\brick.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 source\wall\brick.c
fossil revert -r VERSION source\wall\brick.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:\fossil\castle.fossil
открывать, настраивать и пополнять его,
c:
cd \projects\castle
fossil open c:\fossil\castle.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 в работе над проектом.

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

Подробнее
Реклама

Комментарии 76

    –11
    Опечатка в слове репозитария, должно быть репозитория.
      +1
      Спасибо за подсказку. Исправил.
      +7
      Спасибо за статью, Fossil — действительно интересная штука по своей архитектуре, но, если честно, каких-то преимуществ перед другими DVCS (в частности, перед гитом) пока не видно. На первый взгляд, набор операций, фактически, тот же самый, за исключением непривычных названий (странно, что общепринятый Carriage-Return-Line-Feed здесь назвали Carriage-Return-New-Line). Жду вторую часть :)

      И кстати, «repository» переводится на русский всё же как «репозитoрий». На хабре была не так давно замечательная статья на эту тему, но я её что-то не могу найти…
        +2
        Как раз по архитектуре, кстати, фоссил мало отличается от гита. Просто складывается всё в SQLite, а не в файловую систему, ну и баги-вики есть.

        Интерфейс поудобнее, чем в гите, но до меркуриала — как до луны. Настроить под себя сложно, потому как очень мало «ручек», за которые можно покрутить. Ну и слабое сообщество — тоже не преимущество.
        +7
        Извините за возможно глупый вопрос, но в чем конкретно преимущества fossit перед git'ом? Вики и веб-интерфейсом сейчас никого не удивишь.
          0
          Вики и веб-интерфейсом сейчас никого не удивишь.

          В том числе и на локальном компьютере для локального же репозитория?
            0
            Локальный репозиторий и вовсе меня пугает. Хотя фишка с использованием дропбокса весьма вкусная.
              –2
              Локальный репозиторий и вовсе меня пугает
              Почему? В любой VCS есть и удаленный, и локальный репозитарии.
                0
                Я к тому, что иметь только локальный репозиторий не целесообразно. В данном случае на помощь приходит дропбокс.
                  0
                  Почему нецелесообразно? Dropbox, если я не ошибаюсь хранит версии только месяц.
          +6
          Если при записи в одну единственную БД происходит сбой, весь репозиторий накрывается? Как-то подход git на файлах надежнее выглядит.
          Как поведет себя SQLite с базой размером в гигабайт? Все блобы же в базе, как я понял.
          Что такое открыть/закрыть репозиторий? Почему закрывать не рекомендуется, зачем тогда эта функция вообще?
          Система имеет встроенный ACL что ли? Зачем пользователи нужны на локальной машине?
          Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?

          К сожалению, из статьи я вообще не понял зачем нужен этот Fossil и в чем преимущество, кроме как легкости установки под ОС Windows (а что git или mercurial сложно устанавливаются там?) и легкости копирования репозитория (в git достаточно скопировать директорию .git, если нет возможности сделать git clone)
            0
            Если при записи в одну единственную БД происходит сбой, весь репозиторий накрывается? Как-то подход git на файлах надежнее выглядит.
            Необходимость резервного копирования никто не отменял.

            Как поведет себя SQLite с базой размером в гигабайт?
            Не знаю, не пробовал. Честно говоря, не представляю себе проекта такого размера, если, конечно, большие бинарные файлы в репозиторий не пихать. Учтите к тому же, что Fossil сжимает рабочие файлы. У меня самый большой рабочий каталог исходников — 6 мегабайт с копейками, а соответствующий Fossil репозиторий — чуть больше полутора мегабайт.

            Что такое открыть/закрыть репозиторий? Почему закрывать не рекомендуется, зачем тогда эта функция вообще?
            В тексте же написано — при открытии создается служебная БД для отслеживания изменений в репозитории. Не рекомендую закрывать — просто чтобы не открывать опять, когда на следующий день возьметесь за работу. Можно ведь и забыть.

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

            Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?
            Ниже все правильно ответили. Добавлю, что в Fossil это работает и на локальном компьютере, для локального репозитория, нет нужды в сторонних сервисах, которые могут отвалиться или изменить свою политку в любой момент.
              +2
              Как пользователь Fossil, отвечу на некоторые ваши вопросы:
              Если при записи в одну единственную БД происходит сбой, весь репозиторий накрывается?
              В соответствии с документацией Fossil незавершенная транзакция будет отменена при следующем открытии базы. Такой подход мне кажется более надежным, чем дерево файлов. (оригинал: A Fossil repository is an SQLite database, so it highly resistant to damage from a power-loss or system crash — incomplete transactions are simply rolled back after the system reboots.
              Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?
              — Fossil проектируется как «all in one», основное преимущество fossil перед связкой VCS + WIKI&BugTracker в том, что в fossil для поднятия как локального репозитория, так и сервера для репозиториев необходимо минимальное количество действий, что удобно для домашних и небольших распределенных проектов.
              Как поведет себя SQLite с базой размером в гигабайт?
              Мне сложно представить репозиторий ТАКИХ размеров, но довелось иметь дело с репозиторием размером в 200 мб. Перфоманс упал, но не значительно.
                +2
                В соответствии с документацией Fossil незавершенная транзакция будет отменена при следующем открытии базы. Такой подход мне кажется более надежным, чем дерево файлов.
                Совершенно верно. Процитирую комментарий с stackoverflow:
                The fact that there's a tried'n'true transactional database behind every operation makes me sleep better at night. Yes, we've been through more than one horrible incident of stale and corrupt Subversion repositories (thankfully, a helpful community helped us fix them.) I can't imagine that happening in Fossil. Even Subversion 1.7.x use Sqlite now for metadata storage. (Try turning off power in the midst of a git commit — it'll leave a corrupt repos!)

                Тот факт, что каждая операция обеспечивается реально транзакционной базой данных, позволяет мне спать спокойно. Мы пережили не один ужасный инцидент, связанный с повреждением хранилищ Subversion (к счастью, сообщество помогло нам справиться с ними ). Я не могу себе представить, чтобы такое случилось с Fossil. Даже Subversion 1.7 использует теперь Sqlite для хранения метаданных. ( Попробуйте выключить питание посреди commit в git — ваш репозитарий будет поврежден! )
                  0
                  Попробуйте выключить питание посреди commit в git — ваш репозитарий будет поврежден!

                  Прошу представить доказательство этого.
                    0
                    Наблюдал человека с такой проблемой в Telegram-группе git_ru в прошлом году — или это была потеря питания во время pull c сервера… в общем, репозиторий повредился.
                  +1
                  В соответствии с документацией Fossil незавершенная транзакция будет отменена при следующем открытии базы. Такой подход мне кажется более надежным, чем дерево файлов.


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

                  Fossil проектируется как «all in one»

                  Это вроде как противоречит известным принципам проектирования. Опять же не знаю как в Windows, но в ОС с пактными менеджерами установка что fossil, что git это одно и тоже стандартное действие.

                  Мне сложно представить репозиторий ТАКИХ размеров, но довелось иметь дело с репозиторием размером в 200 мб. Перфоманс упал, но не значительно.

                  $ du -sh .git
                  311M    .git
                  311M    total
                  

                  Это ещё маленький размер. Я в git храню вообще всё, от результатов вычислений (могут быть десятки МБ) до картинок, а не только коды программ. Размер репозиториев ядра Linux, QT, xorg и тп тоже как бы не маленький. Зачем сразу себя загонять в рамки немасштабируемой системы, когда можно пользоваться масштабируемой прикладывая те же усилия?
                    0
                    С чего это он более надёжный не понятно. Git при коммите создаёт только новые новые файлы и не меняет старые, так что испортить ничего не может.


                    предлагаю провести тест и сэмулировать ситуацию с «недописаным» файлом в дереве.

                    для эмуляции я использовал следующие шаги:
                    1) склонировал репозиторий git
                    2) удалил файл с наиболее поздней датой изменения
                    =>

                    $git status
                    fatal: unable to read tree 6b711a2ac75bc3cfe9a37e1d2f263dfef93db584
                    


                    А под «принципами проектирования» вы видимо имеете ввиду философию Unix? Вы действительно считаете, что она подходит под данный случай?

                    Опять же не знаю как в Windows, но в ОС с пактными менеджерами установка что fossil, что git это одно и тоже стандартное действие.

                    Подскажите, какое стандартное действие установит клиент, сервер, wiki, баг трекер и web ui для git? Для fossil это «apt-get install fossil»
                      +1
                      > предлагаю провести тест и сэмулировать ситуацию с «недописаным» файлом в дереве

                      Тест некорректен. При записи коммита сначала записываются блобы, потом tree, потом commit, потом обновляется ветка. Если вы тестируете падение во время записи коммита, откатывайте изменения с конца. Нетрудно видеть, что репозиторий всегда остаётся в консистентном состоянии: ветка обновится только когда коммит будет целиком записан, коммит — только когда будут записаны все его tree, tree — только после блобов, так что как и с транзакцией fossil, потеряем только текущий коммит. Однако, в отличие от fossil, уже записанные части коммита можно будет извлечь, а не потерять навсегда при rollback'е транзакции. Так что git всё-таки надёжнее.
                        0
                        Ок, спасибо за разъяснение.
                          0
                          А я правильно ли я понимаю, что обновление ветки — это обновление файла .../refs/heads/имя_ветки? Если да, то тогда все равно существует возможность поломать репозиторий при отключении питания.
                            0
                            > это обновление файла .../refs/heads/имя_ветки

                            Да.

                            > существует возможность поломать репозиторий при отключении питания

                            Нет. Запись нового файла + rename(2), последний атомарен.
                              0
                              Тогда вопросов больше нет :)
                          0
                          У вас пропала только ссылка на коммит в текущей ветке. Даже сам коммит вы можете извлечь и поставить на него ссылку. Всё. А теперь попробуйте вбить рандомные данные в середину файла SQLite, то же будет ошибка чтения с непредсказуемыми последствиями. С учётом того, что репозиторий это огромный блоб (кто догадался хранить бинарники в базе???) вероятность убить его целиком намного выше, чем испортить всю кучу мелких файлов.

                          А под «принципами проектирования» вы видимо имеете ввиду философию Unix? Вы действительно считаете, что она подходит под данный случай?


                          Причём тут unix, любая модульная программа лучше чем немодульная.

                          Подскажите, какое стандартное действие установит клиент, сервер, wiki, баг трекер и web ui для git? Для fossil это «apt-get install fossil»

                          Вы не поверите, но кроме баг-трекера и wiki это apt-get install git. Любой другой баг-трекер или целый комбайн типа github ставится ненамного сложнее. А теперь как мне удалить баг-трекер и wiki из fossil, если они мне не нужены?
                            0
                            Причём тут unix, любая модульная программа лучше чем немодульная.

                            Вы действительно считаете, что «немодульная» программа — и программа с «all-in-one» функциональностью представленная одним исполняемым файлом это синонимы? Если вас интересует модульность fossil, вы можете ознакомиться с его исходным кодом: www.fossil-scm.org/index.html/tree?ci=trunk
                            Также можете обратить внимание, что сайты fossil и sqlite — полностью созданы с помощью web ui fossil.

                            Вы не поверите, но кроме баг-трекера и wiki это apt-get install git. Любой другой баг-трекер или целый комбайн типа github ставится ненамного сложнее. А теперь как мне удалить баг-трекер и wiki из fossil, если они мне не нужены?


                            На этот вопрос лучше всего ответил автор Fossil:
                            Note that I wrote fossil because no other DVCS met my needs. On the other hand, my needs are not your needs and so only you can judge whether or not fossil is right for you. But I do encourage you to at least have a look at the documentation and try to understand the problem that fossil is trying to solve before you dismiss it.

                            Обратите внимание, что я написал fossil, потому что никакая другая DVCS не соответствовала моим нуждам. C другой стороны, мои нужды — это не ваши нужды, так что только вы можете судить, подходил ли вам fossil. Но я советую вам (призываю вас) хотя бы открыть документацию и попробовать понять задачи, которые fossil пытается решить, прежде чем отказываться от него.
                              0
                              Это всё хорошо, но там тут предлагают пользоваться некой системой, которая не обладает ни единым преимуществом перед другими (кроме баг-трекера) и может делать всё тоже самое, что и другие. "no other DVCS met my needs" я вот и пытаюсь добиться какие my needs заполнил fossil, чего нет в других системах? Если это только баг-треккер, то это печально.
                                0
                                С точки зрения DVCS fossil предоставляет все те же возможности, что и остальные, тут у него ничего нового нет…
                                Основные преимущества fossil — инфраструктурные, именно «all in one»: интегрированость компонентов, общее удобство и комфорт.
                                У меня, например, нет склонности к администрированию, я не хочу отдельно настраивать службы баг–трекинга, вики, блога и пр. следить за их совместимостью, сопрягать их. Я хочу просто работать над своими проектами, и тут fossil как раз предоставляет мне полный комплект необходимых мне средств.
                            +1
                            А теперь попробуйте вбить рандомные данные в середину файла SQLite, то же будет ошибка чтения с непредсказуемыми последствиями. С учётом того, что репозиторий это огромный блоб (кто догадался хранить бинарники в базе???) вероятность убить его целиком намного выше, чем испортить всю кучу мелких файлов.

                            Опять же, никто не ответит на ваш вопрос лучше чем автор fossil:
                            www.fossil-scm.org/index.html/doc/tip/www/selfcheck.wiki

                            Мой тест был некорректен. А вы можете предложить корректный сценарий, при котором в середину sqlite файла попадут рандомные данные (за исключением повреждения носителя)?
                    +11
                    Попробую ответить всем сразу. Я перешёл на fossil с SVN и bazaar для домашних проектов по следующим причинам:
                    1. Как система контроля версий он предоставляет всё то же самое, что и git, mercurial, bazaar и пр. DVCS.
                    2. Его преимущества (для меня) перед остальными:
                    3. Не требует никакой установки, достаточно просто скачать один файл.
                    4. Репозиторий лежит в одном файле, поэтому можно смело бросать его в DropBox, с git такого например делать нельзя. Также сразу отпадает необходимость как-то дома или где-то ещё поднимать сервер
                    5. Встроенный web-ui с распределённой Wiki — позволил закрыть для меня проблему личного сервера заметок. Это особенно удобно, когда нет интернета, но есть клон репозитория на флешке, после восстановления соединения достаточно выполнить слияние.

                    По другим вопросам:
                    1. Как поведет себя SQLite с базой размером в гигабайт? — это скорее всего не будет в его области применимости
                    2. Зачем пользователи нужны на локальной машине? — fossil можно запустить в режиме веб–сервера, и пользователи нужны, чтобы разграничить доступ
                    3. Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS? — интегрированость, отсутствие необходимости особо настраивать, сопрягать и прочих администраторских действий
                    4. Что такое открыть/закрыть репозиторий? — связать/отвязать рабочую папку с репозиторием. Почему не автор статьи не рекомендует закрывать я не знаю, так как если я закончил работу, я обычно удаляю рабочие папки, сохраняя их только в репозитории


                    Резюмируя: fossil полезен тем, что у него «всё включено» и идеально подходит для небольших/домашних нужд.
                      +1
                      Репозиторий лежит в одном файле, поэтому можно смело бросать его в DropBox, с git такого например делать нельзя

                      Не совсем понятно, как Вы «бросаете файлы в Dropbox». У меня десятки git-репозиториев через него синхронизируются между машинами абсолютно без проблем. Не представляю, как у Вас это могло не получиться.
                        +2
                        Есть теоретическая вероятность, что если одновременно коммитить в репозиторий, который лежит в dropbox'е, то он будет порушен, так как Dropbox синхронизирует пофайлово и ничего не знает о структуре git.
                        пример
                          0
                          А, теперь понятно. Да, я не имею привычки находиться одновременно за рабочим и домашним компами, поэтому эта проблема для меня не сильно актуальна. Вот и не подумал о ней.
                            0
                            Для конфликтов в ДропБоксе не обязательно одновременно находиться в разных местах. Достаточно, чтобы в одном из этих мест пропал интернет. Однако и Fossil не защищён от этой проблемы.
                            0
                            Хм, а прямо в примере по Вашей ссылке есть противоположный комментарий:
                            Hey,
                            I've had a github hosted blog sitting on my dropbox for a long time. I use it from various machines and it even has a daily commit job (for those times when my wandering brain forgets to commit changes).

                            Not seen this wonky behavior yet.

                            Понятно, что вероятность потому и называется вероятностью, что случается не всегда и не у всех, однако в случае с повреждениями файлов в Dropbox наш герой Fossil не имеет принципиально большого преимущества. Если повредится файл с его репозиторием, мы ведь точно так же не сможем его прочитать, как и сломанный репозиторий git. Поэтому мне это «преимущество fossil» кажется больше похожим на миф, нежели на факт.
                              +2
                              Здесь имеется ввиду не физическое повреждение файла, а порча структуры: при конфликтах DropBox переименовывает файлы.
                              В случае одного файла это легко заметить, а в случае когда были переименованы файлы где-то внутри .git это будет не так легко.
                                0
                                Суть проблемы стала более понятна, но, повторюсь, ни разу от неё не страдал, несмотря на то, что использую git-репозитории в Dropbox давно и активно. Но на заметку возьму…
                                  0
                                  Не надо так делать. Это опасно, git не расчитан на такое использование. Если нет возможности отказаться от Dropbox, то лучше внутри Dropbox завести bare-репозиторий и сделать его как remote к рабочему.
                                    0
                                    Все мои репозитории в Dropbox именно bare ;) Заметьте, я ни разу не утверждал, что это «рабочие» репозитории.
                              +1
                              Пример несколько неудачен, так как там конфликт между GitHub (приложением) и dropbox. У git вполне простая и понятная иерархия файлов, в случае конфликта на уровне dropbox можно разве что «потерять хеш правильного коммита», что тривиально решается используя «резервную» копию, которую дропбокс делает при «мерже» разных версий.

                              А если конфликт будет на уровне «вот у нас один файл с sqlite, и второй файл, разруливай», то ситуация звучит несколько сложнее.
                                0
                                А если конфликт будет на уровне «вот у нас один файл с sqlite, и второй файл, разруливай», то ситуация звучит несколько сложнее.

                                Это же стандартная ситуацию для DVCS: просто выполняешь слияние репозиториев.
                                  0
                                  Эм… поподробнее, пожалуйста, расскажите, как сливать два SQLIte-файла.
                                    0
                                    Это не просто два SQLite–файла, это два репозитория:
                                    Допустим есть repo.fossil и repo.2014-08-29.fossil
                                    Выбираем repo.fossil как основной, открываем его:
                                    fsl open repo.fossil

                                    Сливаем изменения из второго:
                                    fsl pull repo.2014-08-29.fossil --once

                                    Смотрим, что изменилось, копируем Id второго листа:
                                    fsl ui

                                    Сливаем изменения в текущей рабочей папке:
                                    fsl merge --integrate ID

                                    Фиксируем:
                                    fsl ci

                                    0
                                    Я о том что база данных — это блоб, слияние нельзя (вернее — нетривиально) выполнить вручную. Если fossil умеет разрешать конфликты на уровне двух хранилищ — это хорошо. Если нет, то с дропбоксом у него может возникнуть более существенна проблема чем у git.
                              +1
                              Почему не автор статьи не рекомендует закрывать я не знаю, так как если я закончил работу, я обычно удаляю рабочие папки, сохраняя их только в репозитории

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

                              Резюмируя: fossil полезен тем, что у него «всё включено» и идеально подходит для небольших/домашних нужд.

                              Небольших — понятие относительное. Сам Fossil, да и тот же SQLite вполне благополучно живут на нем. Это, конечно, не очень большие проекты, но и не маленькие.
                                0
                                Я удаляю файлы из принципа, чтобы не было незавершенных работ, изменения которых не отразились в репозитории (был у меня в истории печальный случай).
                                Так я поддерживаю свою внутреннюю дисциплину, а заодно такой подход заставляет внимательно относиться к бэкапам.
                                  0
                                  Каждый день в конце работы делаете commit, close и удаляете файлы? Или я не так понял?
                                    +1
                                    Ещё раз уточню: это всё относится к моим домашним проектам.
                                    А так да, после завершения работы, я всё удаляю, так как к ним я вернусь по мере сил и времени. И это может быть через дни, иногда и месяцы.
                                    На работе я этим, конечно, не занимаюсь, но всё равно чувствую дискомфорт, если у меня долго висят незафиксированные изменения.
                                      0
                                      Опять же не понятно зачем. Можно сделать отдельную ветку для идей и коммитить туда незавершенное, можно делать stash, если не хочется делать коммит прямо сейчас, можно изменить старый коммит через --amend. Любая другая DVCS это позволяет. Что тут даёт fossil с внесением новой сущности открытия/закрытия не понятно.
                                        0
                                        Это уже не относится к fossil или други VCS, просто мои привычки.
                                        открытие/закрытие это не нововведение fossil, а обычный checkout с рабочими папками.
                                +3
                                2. Его преимущества (для меня) перед остальными:
                                3. Не требует никакой установки, достаточно просто скачать один файл.
                                Как ловко у вас n пунктов превратились в n+1. ;-)
                                  0
                                  Репозиторий лежит в одном файле, поэтому можно смело бросать его в DropBox, с git такого например делать нельзя.


                                  В гите достаточно скопировать скрытую папку, разве нет? Много раз переносил репозиторий, проблем не помню.
                                    0
                                    Гит любит использовать soft и hard линки внутри репозитория, а это может смутить dropbox. Но это, как бы, не проблема git совершенно.
                                    0
                                    Встроенный web-ui с распределённой Wiki — позволил закрыть для меня проблему личного сервера заметок. Это особенно удобно, когда нет интернета, но есть клон репозитория на флешке, после восстановления соединения достаточно выполнить слияние.

                                    А расскажите, пожалуйста, поподробнее, как вы организовали работу с заметками с мобильного устройства? Сел изучать fossil с прицелом использовать его как раз для распределённых заметок, но изящного/правильного подхода не вижу.

                                    Для wiki нет merge и возможности организовать древовидную структуру страниц не заметно.
                                    Embedded documentation даёт древовидную структуру, но нельзя править из браузера. Непонятно, можно ли ползать по дереву embedded documentation из браузера. Править в текстовом редакторе и коммитить из консоли на смартфоне, мягко говоря, неудобно.
                                      0
                                      Вопрос, наверное, к Xitsa, пост которого вы процитировали, я сам смартфонами не пользуюсь.
                                      Для wiki нет merge

                                      Т.е., слияние в случае, если параллельно ту же страницу редактирует кто-то другой? Но Xitsa писал о личном сервере заметок.
                                      и возможности организовать древовидную структуру страниц не заметно.

                                      А если списки ( ul, li,… ) руками прописать?
                                        +2
                                        merge может понадобиться если последовательно произвести правки на разных устройствах пока нет сетевой связности.

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

                                        Вообще концепция уже примерно вырисовывается: беру zim, с десктопов всё правлю им. Он хранит заметки в txt файлах c разметкой очень близкой к markdown. Содержимое файлов fossil показывает с форматированием даже если на них перейти из дерева файлов, древовидная структура в zim организуется директориями на диске, так что ручное создание оглавления не понадобится.
                                          0
                                          Я, в принципе, добавил к zim поддержку fossil.
                                          Посмотрим, примут ли в основную ветку.
                                    0
                                    Тоже активно использую fossil для личных нужд потому что нравится. Сложности в коллективных проектах
                                    — трудно убедить коллег, fossil не популярен, его никто не знает и знать не хочет
                                    — мало бесплатных публичных репозитариев, мне всего один известен
                                    — огромная база opensource кода лежит на github.com, bitbucket.org, code.ggogle.com/p/ и доступна для git или hg. А вот я не могу их оттуда clone или fork и интегрировать в проект средствами fossil.
                                      +1
                                      — огромная база opensource кода лежит на github.com, bitbucket.org, code.ggogle.com/p/ и доступна для git или hg. А вот я не могу их оттуда clone или fork и интегрировать в проект средствами fossil.
                                      попробуйте:
                                      cd git-repo
                                      git fast-export --all | fossil import --git new-repo.fossil
                                      


                                      источник: www.fossil-scm.org/index.html/doc/tip/www/inout.wiki
                                      +1
                                      А как у него с поддержкой в разных IDE?

                                      Можно, конечно, и руками всё комитить, и историю изменений смотреть через web UI / в консоли.
                                      Но гораздо удобнее ведь, когда оно всё прямо «на кончиках пальцев».
                                      Вещи вроде маркировки изменённых строк или полноценных рефакторингов (когда не надо сначала переименовывать файл на диске, а потом в Fossil) всё-таки немалого стоят.
                                        0
                                        С поддержкой IDE, насколько мне известно, ситуация печальна :(. C моей точки зрения, это следствие малой распространнености, а не «недоработка» самого Fossil. Если для вас поддержка IDE критична, Fossil может быть не лучшим выбором.
                                        0
                                        Блин, ну не знаю, легкость установки, говорите…
                                        Я, например, даже не помню, как именно устанавливал гит на маке (толи с xcode установился, толи через менеджер пакетов).
                                        Ну то есть, на мой взгляд, скорость установки для системы управления версиями это вообще не тот показатель, который должен рассматриваться ))
                                        Да и потом, на нормальных системах команда вроде apt-get install git — это вообще самый быстрый способ установки, который только можно придумать.
                                        В случае же с Fossil: надо найти их официальный сайт, открыть его, найти, где скачать бинарник, выбрать бинарник под нужную ОС, скачать его, найти его в папке «загрузки», придумать, куда его положить, возможно прописать его в переменную путей — ну капец же!
                                          0
                                          В репозитории вашего дистрибутива не представлен fossil?
                                          Под скоростью установки, думаю, имелось ввиду скорость развертывания всей необходимой инфраструктуры для ведения проекта распределенной командой — DVCS, WIKI, Bug-tracker, Web-Ui. (и это apt-get install fossil, если дистрибутив позволяет, или скачать файл, если нет)
                                          +1
                                          В fossil в графическом режиме удобное представление веток разработки в виде «напластований геологических слоев» (отсюда, кстати, и название fossil — «ископаемое»)

                                          Пример истории чек-инов

                                          Отсюда, кстати, и отсутствие аналога rebase — для разработчиков и пользователей fossil это часть методологии разработки, когда история разработки — нечто важное, что нельзя менять.

                                          А вообще, спор «какая система контроля версий лучше» аналогичен спору «лучший текстовый редактор», «лучшая IDE» и т.д. Кто-то использует fossil, кто-то hg и т.д.
                                            0
                                            Хранение в одном файле базы данных выглядит удобным для личных целей. Хочу поднять систему контроля версий, для контроля своей работы с различными документами. Насколько fossil будет удобен? Исходя, из определенных сооьражений, файл базы будет лежать в папке Dropbox'а, можно ли будет вполне спокойно продолжить работать с репозиторием на другой системе (текущий ПК но с переустановленной ОС, или же совсем иная машина)?
                                              0
                                              Fossil будет очень удобен, если документы текстовые, и просто удобен, если бинарные.
                                              С работой на разных системах проблем не будет, fossil к системе никак не привязывается и состоит из единственного исполняемого файла.
                                                0
                                                А как у него с отслеживанием переименований файл? Столкнулся с тем, что `git log -p` показывает только до момента переименования, причем так, как будто это новый файл. Зная прошлое имя, можно посмотреть и его, но закончится она тоже так, как если файл был удалён. А здесь?
                                                  0

                                                  переименование записывается, копирование — нет

                                                  0
                                                  Столкнулся с тем, что git log -p показывает только до момента переименования, причем так, как будто это новый файл

                                                  Есть опция --follow.

                                                    0

                                                    оно пытается угадывать, что во что переименовалось/скопировалось

                                                      0

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

                                                        0

                                                        каким же это образом hg cp/mv вместо cp/mv является «дополнительным»?

                                                          0

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


                                                          и каким образом дописывание --follow и прочих ключей «угадывай сильнее» не является «дополнительным ручным действием»?

                                                          Таким что нужно намного реже и при необходимости прописывается в алиасы. И дело тут даже не в этом — с забытым $VCS cp/mv ничего уже не сделаешь, история потеряна. А с --follow её можно получить всегда.

                                                            +1

                                                            С --follow её легко можно не получить вообще никогда. LabVIEW, к примеру, хранит исходный код в бинарных файлах, к тому же сжатых и по‐умолчанию содержащих результаты компиляции (хотя те, кто всерьёз использует VCS быстро учится настраивать его так, чтобы не хранил) и кучу других вещей, которые в других языках отсутствуют, не хранятся вместе с исходным кодом или вообще относятся исключительно к IDE (при том из всего разнообразия можно настройкой исключить только результаты компиляции). При этом один файл — одна функция, так что переименования происходят куда как чаще. Как вы думаете, какая максимальная разница между переименованным и исходным файлом? Мне как‐то доводилось видеть 0% по мнению mercurial. Схожесть в 50% после переименования и ещё какого‐то связанного с этим изменения (обычно — такого, без которого обойтись нельзя) уже можно считать хорошей.

                                                              0
                                                              А с --follow её можно получить всегда.

                                                              как вы определяете, когда командовать --follow, а когда — нет? как вы заставляете вебморду а-ля GitHub/GitLab угадывать сильнее?

                                                            0

                                                            и каким образом дописывание --follow и прочих ключей «угадывай сильнее» не является «дополнительным ручным действием»?

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

                                                      Самое читаемое