Главная » Хабрахабр » [Перевод] Почему SQLite не использует Git

[Перевод] Почему SQLite не использует Git

Содержание

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

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

1.1. Правки

Статья несколько раз пересматривалась, чтобы внести ясность, ответить на опасения и тревоги, а также исправить ошибки, выявленные на Hacker News, Reddit и Lobsters. Полная история редактирования здесь.
Все причины, по которым SQLite не использует систему Git, можно выразить одним предложением: ведущий разработчик SQLite считает это неприемлемым. Если вам нравится Git и вы хотите использовать её, то отлично. Я же не люблю Git и предпочел бы что-то получше, на мой взгляд.

Ниже приведены некоторые причины, почему мне не нравится Git:

2.1. Git затрудняет поиск потомков после коммита

Git позволяет легко вернуться назад во времени. Учитывая последний коммит (check-in) в ветке, Git показывает всех его предков. Но движение в другом направлении затруднено. Если взять какой-то прошлый коммит, то в Git довольно сложно узнать, что последовало дальше. Это можно сделать, но достаточно сложно, так что люди редко пользуются такой возможностью. Популярные интерфейсы для Git, такие как GitHub, не поддерживают эту функцию.

Просто это сложно. Да, в Git есть возможность найти потомков. Например, на этой странице StackOverflow описана последовательность команд под Unix для поиска потомков:

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

Но это не совсем то. Такую последовательность команд трудно запомнить и долго набирать (можно создать bash-алиас или маленький shell скрипт, если команда часто используется). Для сравнения, Fossil предлагает такое отображение. Такая команда даёт список потомков без важной для понимания структуры ветвлений. Это огромное подспорье при анализе последствий сделанных изменений.

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

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

2.2. Ментальная модель Git излишне сложна

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

  1. Рабочий каталог.
  2. «Индекс» или область подготовки (staging area).
  3. Локальный заголовок (HEAD).
  4. Локальная копия удалённого заголовка.
  5. Реальный удалённый заголовок.

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

Это на 60% меньше отвлечений. Для сравнения, пользователи Fossil думают только о своём рабочем каталоге и о том коде, над которым работают. Fossil требует меньше рабочей памяти, освобождая интеллектуальные ресурсы непосредственно для программирования. Рабочая память любого разработчика ограничена.

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

«Fossil даёт душевный покой и ощущение, что всё в порядке… синхронизируется с сервером одной командой… Такого душевного спокойствия никогда не было с Git».

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

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

Сравним отображение одной исторической ветки SQLite в GitHub и в Fossil.

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

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

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

Git — это сложное программное обеспечение. Для установки Git на компьютер разработчика или для обновления требуется какой-либо инсталлятор. Настройка сервера Git нетривиальна. Можно было бы использовать GitHub, но это вводит ещё одну стороннюю зависимость, а централизованная служба устраняет ключевое преимущество Git, которое заключается в «распределённости». Существуют различные бесплатные альтернативы вроде GitLab, но там тоже много зависимостей и требуется серьёзная настройка сервера.

Этот единственный бинарник содержит всю функциональность Git, а также и GitHub и/или GitLab. В отличие от них, Fossil — это один отдельный бинарник, который устанавливается путём размещения в $PATH. Он управляет сервером сообщества с вики и баг-трекером, обеспечивает пакетную загрузку для пользователей, управление авторизацией и прочее — без дополнительных программ.

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

2.5. Git неудобен в использовании

Эта карикатура — преувеличение, но бьёт почти в цель:

Он отслеживает совместную работу над проектами с помощью прекрасной распределённой модели деревьев из теории графов.
— Классно.
— Это Git. Просто запомни эти команды шелла. Как её использовать?
— Без понятия. Если выскочит ошибка, сохрани где-нибудь свою работу, удали проект и скачай свежую копию.
Вводи их, когда нужно синхронизироваться.

Мало кто спорит, что у Git неоптимальный пользовательский интерфейс. Будем реалистами. Он настолько плох, что есть даже пародийный сайт, который генерирует страницы фейкового мануала git.

Это требует большой концентрации. Проектировать ПО сложно. За последнее десятилетие Git стал лучше в этом отношении, но предстоит пройти ещё долгий путь. Хорошая система управления версиями должна помогать разработчику, а не огорчать его. До тех пор разработчики SQLite продолжат использовать другую систему управления версиями.

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

3.1. Зеркала на GitHub

Есть зеркало дерева исходного кода SQLite на GitHub. Его поддерживает пользователь mackyle, который не связан с командой разработчиков SQLite и неизвестен нам. Мы не знаем Маккайла, но видим его потрясающую работу по поддержанию зеркала в актуальном состоянии. Поэтому если хотите получить доступ к исходному коду SQLite на GitHub, то его зеркало — рекомендуемый источник.

3.2. Доступ через веб

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

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

Это может быть префикс криптографического хэша определенного включения или имя ветви (в таком случае выбирается последняя версия ветви), или тег для конкретного билда, например, “version-3. Просто замените VERSION на номер загружаемой версии. 1”: 23.

23. https://sqlite.org/src/tarball/version-3. 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

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

  1. Загрузите автономный исполняемый файл Fossil с этой страницы и поместите его где-нибудь в $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” для последней версии SQLite. вики для дополнительной информации, какие имена можно использовать для VERSION. См.

Команда fossil ui в ~/sqLite поднимает локальную копию веб-сайта.

здесь. Дополнительную документацию по Fossil см.

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

Вот ещё несколько страниц, где обсуждаются Fossil и Git:


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

«Чтение на выходные»: 25 материалов для начинающих любителей винила

Сегодня мы подобрали материалы из «Мира Hi-Fi» специально для начинающих и всех, кто хотел бы познакомиться с экосистемой винила, подобрать проигрыватель и разобраться с настройкой. Фото Best Picko / CC Выбор проигрывателя Назад к винилу — вперед к настоящему звуку. ...

[Перевод] Оптимизация рендеринга сцены из диснеевского мультфильма «Моана». Часть 2

Вдохновлённый первой победой при парсинге с помощью описания сцены острова из мультфильма «Моана» компании Disney, я далее углубился в изучение использования памяти. Можно было сделать ещё очень многое со временем выполнения, но я решил, что будет полезно сначала разведать обстановку. ...