[Перевод] Почему SQLite не использует Git17.04.2018 15:03

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

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

1.1. Правки

Статья несколько раз пересматривалась, чтобы внести ясность, ответить на опасения и тревоги, а также исправить ошибки, выявленные на Hacker News, Reddit и Lobsters. Полная история редактирования здесь.

2. Несколько причин, почему SQLite не использует Git
Все причины, по которым 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 ".\{40\}.*.*" | awk '{print $1}'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Руководство пользователя 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 на номер загружаемой версии. Это может быть префикс криптографического хэша определенного включения или имя ветви (в таком случае выбирается последняя версия ветви), или тег для конкретного билда, например, «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

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 см. здесь.

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

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

• Fossil против Git
• Что другие говорят о Fossil и Git

© Habrahabr.ru