Mercurial 或 git 的关系数据库后端
我喜欢 fossil 的是它使用普通的旧 sqlite 来存储变更集、文件等。我可以使用它的命令行工具可以查询存储库，但如果我想要它不支持的东西，我可以回退到编写 sql 查询。
Mercurial 和 git 更成熟，它们有更多的库，更有动力，但它们使用自己的存储库格式。我想知道是否可以将 sqlite 作为其存储库后端。 （我知道有工具可以直接查询 Mercurial 或 git 存储库，但 sql 似乎更容易。）
What I like about fossil is that it uses plain old sqlite to store changesets, files, etc. I can use its command line tool to query the repository, but if I want something not supported by it, I can fallback to writing an sql query.
Mercurial and git are more mature, they have more libraries, more momentum, but they use their own repository format. I wonder if it's possible to have sqlite as their repository backend. (I know there are tools to query a mercurial or git repo directly, but sql seems easier.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正如 Jefromi 所写，Mercurial 还使用自定义格式来实现高压缩和快速访问任何修订版本。这是 revlog 格式，它是一种仅附加数据结构，利用Mercurial 中变更集的不变性。
但是，如果您愿意，当然可以用另一种存储格式替换此存储格式。 Google 在将 Mercurial 放在 Bigtable 上代码时就是这样做的。 google.com。他们使用自己的后端格式的一个有趣的后果是，您在他们的网络界面中看不到任何修订号。在正常的 Mercurial 中，修订号（可以使用的本地整数，而不是完整的变更集哈希）是修订日志中变更集的索引。当变更集未存储在修订日志中时，就没有自然索引，因此 Google 不会向您显示修订号。
As Jefromi writes, Mercurial is also using a custom format to achive high compression and fast access to any revision. This is the revlog format which is an append-only data structure that takes advantage of the immutability of changesets in Mercurial.
However, it is of course possible to replace this storage format with another if you like. Google did this when they put Mercurial on Bigtable for code.google.com. One funny consequence of them using their own backend format is that you don't see any revision numbers in their web interface. In normal Mercurial, the revision numbers (the local-only integer you can use instead of the full changeset hash) are the index of the changesets in the revlog. When changesets are not stored in revlogs, there is no natural index and therefore Google shows you no revision numbers.
对于 git，存储库格式是一切工作方式的一个非常基本的部分。你必须做很多工作才能改变这一点。
我还没有阅读过 Mercurial 的任何来源，但我想情况并没有太大不同。
正如我在评论中所建议的，我不太确定你为什么要这样做。为了让 git 仍然能够拥有其所有优势，您必须将 git 对象存储在 sqlite 数据库中。您仍然需要所有低级 git 工具来访问和操作它们 - 您不会只是通过 SHA1 查找 blob 和树并自己完成所有其余工作。 （即使出于某种原因您想要这样做，您也可以通过查看 git 对象目录来轻松做到这一点。）
我的建议是，如果您发现您想要在 git 中执行的某些操作不受支持，您熟悉一些管道命令并弄清楚如何将它们编写为脚本。 Git 确实公开了您可能想要的最低级别的操作。
PS 如果您应该找到想要执行的特定不受支持的操作，并且无法找到执行该操作所需的管道或实现该操作所需的脚本，请在此处发布问题！没有理由因为不会使用 sql 而陷入困境。
With git, the repository format is a pretty fundamental part of the way everything works. You'd have to do a lot of work to change that.
I haven't read any of mercurial's source, but I imagine the situation isn't much different.
As I suggested in my comment, I'm not really sure why you'd want to do this. For git to still be able to have all of its advantages, you'd have to store git objects in your sqlite database. You'd still need all of the low-level git tools to access and manipulate them - you're not going to be just looking up blobs and trees by their SHA1s and doing all the rest of the work yourself. (And even if for some reason you wanted to, you could do that just as easily by looking in the git objects directory.)
My suggestion would be that, if you find that there are operations you want to perform in git that are unsupported, you familiarize yourself with some of the plumbing commands and figure out how to write them as scripts. Git really does expose pretty much the lowest level of operations you could want.
P.S. If you should find a specific unsupported operation you want to do, and are having trouble finding the plumbing you need to perform it, or with the scripting necessary to implement it, post a question here! No reason to get stuck just because you can't use sql.
libgit2 后端是可能的：
https://github.com/libgit2/libgit2-backends/blob /master/sqlite/sqlite.c
我还没有进行任何测量，但性能应该会受到一些影响。然而，它也更方便（整个存储库历史记录的单个文件、经典的 SQL 查询语言......等等）
It's possible with libgit2 backends :
https://github.com/libgit2/libgit2-backends/blob/master/sqlite/sqlite.c
I haven't done any measurement, but performance should suffer a bit. However, it's also more convenient (single file for the entire repo history, classic SQL query language..etc..)
对于 Git 来说，你不能使用与官方二进制文件不同的后端。但是，libgit2 项目允许您使用不同的后端来存储数据库。但是，您必须构建想要用于提交、合并、推送、拉取、变基等的所有二进制文件。此外，您将无法使用官方二进制文件修改您的存储库。您必须首先将其推送到标准存储库。
Speaking for Git, you cannot use different backend with the official binaries. However, the libgit2 project allows you to use different backends to store the database. However, you'll have to build all the binaries you wish to use for committing, merging, pushing, pulling, rebasing, etc. Also, you won't be able to modify your repository with the official binaries. You'll have to push it to a standard repo first.