Бэкэнд реляционной базы данных для Mercurial или Git - PullRequest
13 голосов
/ 19 августа 2010

Что мне нравится в fossil , так это то, что он использует простой старый sqlite для хранения наборов изменений, файлов и т. Д. Я могу использовать его инструмент командной строки для запроса к хранилищу, но если я хочу что-то, что не поддерживается имЯ могу вернуться к написанию SQL-запроса.

Mercurial и git более зрелые, у них больше библиотек, больше импульса, но они используют свой собственный формат репозитория.Интересно, возможно ли использовать sqlite в качестве бэкэнда хранилища?(Я знаю, что есть инструменты для непосредственного запроса ртути или git-репо, но sql кажется проще.)

Ответы [ 4 ]

13 голосов
/ 21 августа 2010

Как пишет Джефроми, Mercurial также использует собственный формат для достижения высокой степени сжатия и быстрого доступа к любой ревизии. Это формат revlog , представляющий собой структуру данных только для добавления, которая использует неизменность наборов изменений в Mercurial.

Однако, конечно, можно заменить этот формат хранения на другой, если хотите. Google сделал это, когда разместил Mercurial на Bigtable для code.google.com. Одно забавное следствие того, что они используют собственный формат бэкэнда, это то, что вы не видите номеров ревизий в их веб-интерфейсе. В обычном Mercurial номера ревизий (локальное целое число, которое вы можете использовать вместо полного хэша наборов изменений) являются индексом наборов изменений в журнале изменений. Когда наборы изменений не хранятся в журналах изменений, естественный индекс отсутствует, и поэтому Google не показывает номеров версий.

12 голосов
/ 19 августа 2010

С git формат репозитория является довольно фундаментальной частью того, как все работает.Вам бы пришлось проделать большую работу, чтобы изменить это.

Я не читал ни одного источника Mercurial, но я думаю, что ситуация не сильно отличается.

Как я и предлагалв моем комментарии я не совсем уверен, почему вы хотите сделать это.Чтобы git мог по-прежнему иметь все свои преимущества, вы должны хранить объекты git в своей базе данных sqlite.Вам по-прежнему нужны все низкоуровневые инструменты git для доступа к ним и манипулирования ими - вам не нужно будет просто просматривать блобы и деревья по их SHA1 и выполнять всю остальную работу самостоятельно.(И даже если по какой-то причине вы захотите, вы можете сделать это так же легко, заглянув в каталог объектов git.)

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

PS Если вам нужно найти конкретную неподдерживаемую операцию, которую вы хотите выполнить, и у вас возникли проблемы с поиском нужной вам сантехники, или ссценарии, необходимые для его реализации, оставьте вопрос здесь!Нет причин застрять только потому, что вы не можете использовать sql.

7 голосов
/ 20 июня 2013

Это возможно с бэкэндами libgit2: https://github.com/libgit2/libgit2-backends/blob/master/sqlite/sqlite.c

Я не делал никаких измерений, но производительность должна немного пострадать. Однако это также более удобно (один файл для всей истории репо, классический язык запросов SQL и т. Д.)

1 голос
/ 16 октября 2013

Говоря о Git, вы не можете использовать другой бэкэнд с официальными двоичными файлами. Однако проект libgit2 позволяет использовать разные бэкэнды для хранения базы данных. Однако вам придется собрать все двоичные файлы, которые вы хотите использовать для фиксации, слияния, добавления, извлечения, перебазирования и т. Д. Кроме того, вы не сможете изменить свой репозиторий с помощью официальных двоичных файлов. Сначала вам придется подтолкнуть его к стандартному репо.

...