Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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