RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 		 Visa 
4274 3200 2453 6495 

Small. Fast. Reliable.
Choose any three.
Почему SQLite не использует Git
►Оглавление

1. Введение

SQLite не использует систему управления версиями Git. SQLite использует вместо этого Fossil, которая является системой управления версиями, которая была специально написана, чтобы поддержать SQLite.

Люди часто задаются вопросом, почему SQLite не использует систему управления версиями Git как все другие. Эта статья пытается ответить на тот вопрос. Кроме того, в разделе 3 эта статья предоставляет советы пользователям Git о том, как они могут легко получить доступ к исходному коду SQLite.

Эта статья не сравнение между Fossil и Git. См. https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki для сравнения этих двух систем. Другие сторонние сравнения доступны также, используйте любую поисковую систему, чтобы найти их.

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

1.1. Правки

Эта статья была пересмотрена многократно в попытке улучшить ясность, проблемы адреса и опасения и исправить ошибки. Полная история правок для этого документа может быть найдена в https://sqlite.org/docsrc/finfo/pages/whynotgit.in. Нажмите на какие-либо два узла графа для различного BTW, есть ли какие-либо веб-интерфейсы Git, которые предлагают подобную способность?

2. Несколько причин, почему SQLite не использует Git

2.1. Git не обеспечивает хорошую ситуативную осведомленность

Когда я хочу видеть то, что происходило на SQLite, я посещаю timeline и на единственном экране я вижу резюме последних изменений на всех ветках. В нескольких щелчках я могу получить столько деталей, сколько я хочу. Я могу даже сделать это с телефона.

GitHub и GitLab не предлагают ничего сопоставимого. Самой близкой, которую я нашел, является network , которая не спешит отдавать (если она еще не кэшировала), не предлагает почти столько же деталей и едва работает вообще с мобильным телефоном. Просмотр коммитов GitHub обеспечивает больше деталей, отдает быстро и работает со смартфонами, но только показывает единственное отделение за один раз, таким образом, я не могу легко знать, видел ли я все недавние изменения. И даже если GitHub/GitLab действительно предлагал лучшие интерфейсы, оба это сторонние услуги. Они не основная часть Git. Следовательно, использование их вводит еще одну зависимость в проект.

Мне говорят, что пользователи Git обычно устанавливают сторонние графические смотрелки для Git, многие из которых делают лучшую работу по показу недавней деятельности по проекту. Это дает еще больше сторонних приложений, которые должны быть установлены и организованы отдельно. Многие определенные для платформы. Один из лучших GitUp работает только на Mac, например. Все требуют, чтобы вы сначала синхронизировали свой локальный репозиторий, тогда поднимают их графический интерфейс на вашем рабочем столе. И даже со всем этим, я все еще не вижу то, что я, как правило, хочу видеть без многократных щелчков.

2.2. Git мешает находить преемников (потомков) регистрации

Git позволяет вам посмотреть назад, но не вперед. Учитывая некоторую историческую регистрацию, вы видите то, что прибыло прежде, но сложно увидеть то, что прибыло позже.

Fossil предлагает полезные показы, такие как https://sqlite.org/src/timeline?df=major-release, чтобы показать все регистрации, которые получены из новой главной версии.

Возможно найти потомков регистрации в Git. Это просто трудно. Например, есть stackoverflow page, показывающая последовательность команд для нахождения потомков регистрации в Unix:

git rev-list --all --parents | grep ".\{40\}.*.*" | awk '{print $1}'

Но это не то же самое. Команда выше дает список потомков, не показывая ветвящуюся структуру, которая важна для понимания, что произошло. И команда работает только, если у вас есть местный клон хранилища, нахождение потомков регистрации не является чем-то, что можно сделать с веб-интерфейсами, такими как GitHub или GitLab.

Это делает сложным нахождение потомков регистрации время от времени. То, что потомки легко доступны в Fossil означает, что информация проникает в веб-страницы, обеспеченные Fossil. Один пример: каждая страница информации о регистрации Fossil (пример) показывает маленький граф "Context" непосредственного предшественника и преемников той регистрации. Это помогает пользователю поддержать лучшую ситуативную осведомленность, и она обеспечивает полезные возможности, такие как способность щелкнуть вперед к следующей регистрации в последовательности. Другой пример: Fossil легко показывает контекст вокруг определенной регистрации ( пример), что снова помогает способствовать ситуативной осведомленности и более глубокому пониманию того, что происходит в коде. Есть целая страница дополнительных примеров в документации Fossil.

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

2.3. Умственная модель для Git слишком сложна

Сложность Git отвлекает внимание от разрабатываемого программного обеспечения. Пользователь Git должен иметь в виду все следующее:

  1. Рабочий каталог
  2. "index" или район сосредоточения
  3. Местный заголовок
  4. Местная копия удаленного заголовка
  5. Фактическая удаленный заголовок

У Git есть команды (и/или варианты по командам) для перемещения и сравнения содержания между всеми этими местоположениями.

Пользователи Fossil должны думать только об их рабочем каталоге и регистрации, они продолжают работать. Это на 60% меньше отвлечения. У каждого разработчика есть конечное число мозговых циклов. Fossil требует, чтобы меньше мозговых циклов работало, таким образом освобождая интеллектуальные ресурсы, чтобы сосредоточиться на разрабатываемом программном обеспечении.

Один пользователь Git и Fossil пишет в HN:

Fossil gives me peace of mind that I have everything ... synced to the server with a single command.... I never get this peace of mind with git.

2.4. Git не отслеживает исторические названия отделения

Git держит полный DAG последовательности регистрации. Но теги ветвей это местная информация, которая не синхронизируется и не сохраняется, как только отделение закрывается. Это делает обзор исторических отделений утомительным.

Как пример, предположите, что клиент спрашивает вас: "Что когда-нибудь случилось в отделении 'prefer-coroutine-sort-subquery' за последние два года?" Вы могли бы попытаться ответить, консультируясь с историей в вашей системе управления версиями, таким образом:

Представление Fossil ясно показывает, что отделение было в конечном счете слито назад в ствол. Это показывает, где отделение началось, и это показывает два случая, где изменения в стволе были слиты в отделение. GitHub не показывает ничего из этого. На самом деле показ GitHub главным образом бесполезен в попытке выяснить то, что произошло.

Многие читатели рекомендовали различный сторонний GUI для Git, который мог бы сделать лучшую работу по показу исторических опытно-конструкторских разработок. Возможно, некоторые из них действительно работают лучше, чем Git и/или GitHub, хотя им будет препятствовать то, что Git не сохраняет исторические названия отделения через синхронизации. И даже если те другие инструменты лучше, то, что необходимо пойти в сторонний инструмент, чтобы получить желаемую информацию, не говорит ничего хорошего об основной системе.

2.5. Git требует большей административной поддержки

Git сложное программное обеспечение. Каждому нужен инсталлятор некоторого вида, чтобы поместить Git на рабочую станцию разработчика или модернизировать до более новой версии Git. Поставить сервер Git не так-то просто, большинство разработчиков использует стороннюю службу, такую как GitHub или GitLab, и таким образом вводит дополнительные зависимости.

Fossil это единственный автономный исполняемый модуль, который устанавливается, помещая его в $PATH. Тот модуль содержит всю функциональность основного Git, а также GitHub/GitLab. Это управляет сервером сообщества с Wiki, отслеживанием ошибок и форумом, предоставлет упакованные загрузки потребителям, управление логинами и т. д. без дополнительного программного обеспечения. Установка сервера сообщества для Fossil занимает минуты. Fossil эффективен. Сервер Fossil будет хорошо работать на VPS за $5/месяц или Raspberry Pi, тогда как GitLab и подобные требуют более раскормленных аппаратных средств.

Меньше администрации подразумевает, что программисты проводят больше времени, работая над программным обеспечением (SQLite в этом случае) и меньше времени носятся с системой управления версиями.

2.6. Git обеспечивает плохой пользовательский опыт

Следующий https://xkcd.com/1597/ мультфильм является преувеличением, но все же попадает близко к теме:

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

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

3. Руководство пользователя Git по доступу к исходному коду SQLite

Если вы преданный пользователь Git, можно все еще легко получить доступ к SQLite. Эта секция дает некоторые советы о том, как это сделать.

3.1. Официальное зеркало GitHub

С 2019-03-20 есть официальное зеркало Git SQLite на GitHub.

Зеркало это экспорт канонического хранилища Fossil SQLite. cron-job обновляет хранилище GitHub раз в час. Это одностороннее кодовое зеркало только для чтения. Никакие запросы pull или changes не приняты через GitHub. Хранилище GitHub просто копирует содержание хранилища Fossil. Все изменения вводятся через Fossil.

Хэши, которые определяют регистрации и файлы на зеркале Git, отличаются от хэшей в Fossil. Есть много причин этого, главная в том, что Fossil использует SHA3-256, а Git SHA1. Во время экспорта оригинальный хэш Fossil для каждой регистрации добавляется как нижняя сноска к комментариям регистрации. Чтобы избежать беспорядка, всегда используйте оригинальный хэш Fossil, а не Git, обращаясь к регистрациям SQLite.

3.2. Web Access

SQLite Fossil Repository содержит связи для загрузки Tarball, архива ZIP или SQLite Archive для любой исторической версии SQLite. URL для этих загрузок просты и могут быть легко включены в автоматизированные инструменты. Формат:

https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz

Просто замените VERSION некоторым описанием версии, которая будет загружена. VERSION может быть префиксом шифровального названия хэша определенной регистрации или названия отделения (в этом случае, новая версия отделения получена) или признаком для определенной регистрации, как "version-3.23.1":

https://sqlite.org/src/tarball/version-3.23.1/sqlite.tar.gz

Чтобы получить последний выпуск, используйте "release" для VERSION:

https://sqlite.org/src/tarball/release/sqlite.tar.gz

Чтобы получить последнюю регистрацию ствола, укажите "trunk" для VERSION:

https://sqlite.org/src/tarball/trunk/sqlite.tar.gz

Для архивов ZIP и архивов SQLite, просто измените элемент "/tarball/" на "/zip/" или "/sqlar/" и возможно также поменяйте имя файла загрузки, чтобы иметь суффикс ".zip" или ".sqlar".

3.3. Fossil Access

Fossil легко установить и использовать. Вот шаги для Unix (Windows настраивается аналогично).

  1. Загрузите отдельный исполняемый файл Fossil с https://fossil-scm.org/fossil/uv/download.html и поместите исполняемый файл где-нибудь в $PATH.
  2. mkdir ~/fossils
  3. fossil clone https://sqlite.org/src ~/fossils/sqlite.fossil
  4. mkdir ~/sqlite; cd ~/sqlite
  5. fossil open ~/fossils/sqlite.fossil

В этом пункте вы готовы напечатать "./configure; make" (в Windows с MSVC "nmake /f Makefile.msc").

Чтобы изменить ваш контроль на иную версию Fossil, используют команду "update":

fossil update VERSION

Используйте "trunk" для VERSION, чтобы получить последнюю версию ствола SQLite. Или используйте префикс шифровального имени хэша, название некоторого отделения или признака. См. https://fossil-scm.org/fossil/doc/trunk/www/checkin_names.wiki для большего количества предложений о том, какие имена могут использоваться для VERSION.

Используйте "fossil ui" из ~/sqlite checkout, чтобы поднять местную копию веб-сайта.

Дополнительная документация по Fossil может быть найдена на https://fossil-scm.org/fossil/doc/trunk/www/permutedindex.html.

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

3.4. Подтверждение целостности исходного кода

Если необходимо проверить, что исходный код SQLite, который вы имеете, подлинен и не был изменен ни в каком случае (возможно, противником), это может быть сделано, используя несколько простых инструментов командной строки. В корне дерева исходного текста SQLite есть файл, названный "manifest". Он содержит название любого файла в исходном дереве вместе с хэшем SHA1 или SHA3-256 для того файла (SHA1 используется для более старых файлов, SHA3-256 для более новых). Можно написать скрипт, чтобы извлечь эти хэши и проверить их против файлов исходного кода. Название хэша регистрации это просто хэш SHA3-256 самого файла "manifest", возможно с опущенной последней строкой, если последняя строка начинается с "# Remove this line...".

4. См. также

Другие страницы, которые говорят о Fossil и Git, включают: