Бэкэнд реляционной базы данных для mercurial или git
Мне нравится ископаемых это то, что он использует простой старый sqlite для хранения наборов изменений, файлов и т. д. Я могу использовать его инструмент командной строки для запроса репозитория, но если я хочу, чтобы что-то не поддерживалось им, я могу вернуться к написанию sql-запроса.
Mercurial и git более зрелые, у них больше библиотек, больше импульса, но они используют свой собственный формат репозитория. Интересно, можно ли использовать sqlite в качестве бэкэнда репозитория. (Я знаю, что есть инструменты для запроса РЕПО mercurial или git напрямую, но sql кажется проще.)
4 ответов
с git формат репозитория является довольно фундаментальной частью того, как все работает. Тебе придется много работать, чтобы это изменить.
Я не читал ни одного источника mercurial, но я полагаю, что ситуация не сильно отличается.
Как я предложил в мой комментарий, Я не совсем уверен, почему вы хотите это сделать. Чтобы git все еще мог иметь все свои преимущества, вам придется хранить объекты git в вашей базе данных sqlite. Тебе все еще нужны все низкоуровневые инструменты git для доступа к ним и управления ими - вы не будете просто искать капли и деревья по их SHA1 и делать всю остальную работу самостоятельно. (И даже если по какой-то причине вы хотите, вы можете сделать это так же легко, посмотрев в каталоге объектов git.)
мое предложение состояло бы в том, что, если вы обнаружите, что есть операции, которые вы хотите выполнить в git, которые не поддерживаются, вы ознакомитесь с некоторыми командами сантехники и выясните, как писать их как сценарии. Git действительно раскрывает практически самый низкий уровень операций, который вы могли бы хотеть.
P.S. Если вы должны найти конкретную неподдерживаемую операцию, которую вы хотите сделать, и у вас возникли проблемы с поиском сантехники, вам нужно ее выполнить, или со сценариями, необходимыми для ее реализации, напишите вопрос здесь! Нет причин застревать только потому, что вы не можете использовать sql.
Как пишет Jefromi, Mercurial также использует пользовательский формат для достижения высокого сжатия и быстрого доступа к любой ревизии. Это формат revlog который является структурой данных только для добавления, которая использует неизменность наборов изменений в Mercurial.
однако, конечно, можно заменить этот формат хранения другим, если хотите. Google сделал это, когда они поставили Mercurial на Bigtable для code.google.com - ... Одно забавное следствие из них, использующих свой собственный формат бэкэнда, вы не видите никаких номеров версий в их веб-интерфейсе. В нормальном Mercurial номера ревизий (локальное целое число, которое вы можете использовать вместо полного хэша набора изменений) являются индексом наборов изменений в revlog. Когда наборы изменений не хранятся в revlogs, нет естественного индекса, и поэтому Google не показывает вам номера ревизий.
это возможно с бэкэндами libgit2 : https://github.com/libgit2/libgit2-backends/blob/master/sqlite/sqlite.c
Я не делал никаких измерений, но производительность должна страдать немного. Однако это также более удобно (один файл для всей истории РЕПО, классический язык запросов SQL..так далее..)
говоря для Git, вы не можете использовать другой бэкэнд с официальными двоичными файлами. Однако проект libgit2 позволяет использовать различные модули для хранения базы данных. Однако вам придется создать все двоичные файлы, которые вы хотите использовать для фиксации, слияния, подталкивания, вытягивания, перебазирования и т. д. Кроме того, вы не сможете изменить свой репозиторий с официальных бинарников. Сначала вам придется нажать на стандартное РЕПО.