SQLite 和 SQLite版本控制系统
前言：我不尝试编写 Subversion 或任何其他版本控制系统的替代方案。
我想知道 SQLite 是否有能力用单文件数据库文件（其中不同版本存储为 BLOB）来替换版本控制系统的常用存储库？
Foreword: I am not trying to write an alternative either to Subversion or to any other versioning system.
I wonder if SQLite has what it takes to replace the usual repositories of versioning systems by a single-file database file where different versions are stored as BLOBs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Fossil 是一个用 SQLite 实现的版本控制系统。它使用单个数据库，将版本存储为 BLOB 。
Fossil is a version control system implemented in SQLite. It uses a single database, storing the versions as BLOBs.
并非所有版本控制系统都使用文件系统。
事实上，这样的分布式版本控制系统 Monotone 已经使用 SQLite 进行存储。常见问题解答为什么使用嵌入式 SQL 数据库而不是 Berkeley DB？ 给出了这种选择的一些理由。不过，常见问题解答并未解决“为什么不使用文件系统存储”的问题。
即使 SVN，至少在历史上，也支持 备用 BDB 存储库数据存储。虽然这不是 SQLite，但很容易想象 SQLite 可以充当支持 SQL 作为接口的“超级”BDB。 （实际上，BDB 甚至可以用作 SQLite 后端，收费:-)
请记住，无论数据（差异/增量）存储在何处，最终都会以某种形式的“BLOB”——BDB 值、数据一个文件，或者SQLite 数据库中的 BLOB 列。
快乐编码
Not all version control systems use the filesystem.
In fact, one such distributed version control system, Monotone, already uses SQLite for storage. The FAQ Why an embedded SQL database, instead of Berkeley DB? gives some rational for this choice. The FAQ doesn't address "why not filesystem storage" though.
Even SVN, at least historically, supports an alternate BDB repository data-store. While this is not SQLite it is easy to imagine that SQLite can function as a "super" BDB that supports SQL as an interface. (Actually, BDB can even be used as an SQLite back-end, for a fee :-)
Keep in mind that, no matter where the data (diffs/deltas) is stored it all ends up as some form of "BLOB" -- BDB value, data in a file, or BLOB column in a[n SQLite] database.
Happy coding