backend de base de données relationnelle pour Mercurial ou git

Question

Ce que je aime fossile est qu'il utilise le bon vieux SQLite pour stocker changesets, fichiers, etc. Je peux utiliser son outil de ligne de commande pour interroger le référentiel, mais si je veux quelque chose de pas pris en charge par elle, je peux écrire fallback à une requête SQL.

Mercurial et git sont plus matures, ils ont plus de bibliothèques, plus dynamique, mais ils utilisent leur propre format référentiel. Je me demande s'il est possible d'avoir SQLite comme backend référentiel. (Je sais qu'il existe des outils pour interroger un repo Mercurial ou git directement, mais sql semble plus facile.)

Answer 1

Avec git, le format de stockage est une partie assez fondamentale de la façon dont tout se fonctionne. Il faudrait faire beaucoup de travail à changement.

Je n'ai pas lu de la source de mercure, mais j'imagine que la situation ne diffère pas beaucoup.

Comme je l'ai suggéré dans mon commentaire, je ne suis pas vraiment sûr pourquoi vous voulez faire. Pour git d'être encore en mesure d'avoir tous ses avantages, vous auriez à stocker des objets git dans votre base de données SQLite. Vous auriez encore besoin de tous les outils git bas niveau d'accès et de les manipuler - vous n'êtes pas va être juste regarder les blobs et les arbres par leurs SHA1s et de faire tout le reste du travail vous-même. (Et même si, pour une raison que vous vouliez, vous pouvez le faire tout aussi facilement en regardant dans le répertoire git objets.)

Ma suggestion serait que, si vous trouvez qu'il ya des opérations que vous souhaitez effectuer dans git qui sont non pris en charge, vous familiariser avec quelques-unes des commandes de plomberie et figure sur la façon de les écrire sous forme de scripts. Git vraiment exposer à peu près le plus bas niveau des opérations que vous pourriez souhaiter.

P.S. Si vous trouvez une opération non prise en charge spécifique que vous voulez faire, et la difficulté à trouver la plomberie, vous devez l'exécuter, ou avec le script nécessaire pour la mettre en œuvre, poser une question ici! Aucune raison de se coincer juste parce que vous ne pouvez pas utiliser SQL.

Answer 2

Comme Jefromi écrit, Mercurial utilise également un format personnalisé à achive haute compression et l'accès rapide à toute révision. Ce format est revlog qui est une structure de données append seule qui profite de la immuabilité de changesets dans Mercurial.

Cependant, il est bien sûr possible de remplacer ce format de stockage avec un autre si vous le souhaitez. Google a fait quand ils ont mis sur Mercurial BigTable pour le code. google.com. Une conséquence drôle d'entre eux en utilisant leur propre format de back-end est que vous ne voyez pas les numéros de révision dans leur interface web. Dans Mercurial normale, les numéros de révision (l'entier locale seulement vous pouvez utiliser au lieu de la pleine hachage changeset) sont l'indice des changesets dans le revlog. Lorsque changesets ne sont pas stockés dans revlogs, il n'y a pas d'index naturel et donc Google vous montre aucun numéro de révision.

Answer 3

Il est possible avec libgit2 backends: https://github.com/libgit2/libgit2-backends/blob /master/sqlite/sqlite.c

Je n'ai pas fait de mesure, mais la performance devrait souffrir un peu. Cependant, il est également plus pratique (fichier unique pour l'ensemble de l'histoire des prises en pension, language..etc classique de requête SQL ..)

Answer 4

Parlant au nom de Git, vous ne pouvez pas utiliser différents backend avec les binaires officiels. Cependant, le projet de libgit2 vous permet d'utiliser différents backends pour stocker la base de données. Cependant, vous devrez construire tous les binaires que vous souhaitez utiliser pour commettre, fusion, pousser, tirer, rebasage, etc. De plus, vous ne pourrez pas modifier votre référentiel avec les binaires officiels. Vous devrez pousser à une prise en pension standard de première.