You seem to be making a lot of assumptions, possibly based on your experience with SVN and CVS.
Git and Mercurial are basically like SVN and CVS
Comparing git and CVS is like comparing an iPad and an Atari. CVS was created back when dinoaurs roamed the Earth. Subversion is basically an improved version of CVS. Assuming that modern version control systems like git and Mercurial work like them makes very little sense.
A relational database is more efficient than a single-purpose database
Why? Relational databases are really complicated, and may not be as efficient as single-purpose databases. Some differences off the top of my head:
- Version control systems don't need complicated locking, since you can't do multiple commits at the same time anyway.
- Distributed version control systems need to be very extremely space efficient, since the local database is a full copy of the repo.
- Version control systems only need to look up data in a couple specific ways (by author, by revision ID, sometimes full-text search). Making your own database that can handle author/revision ID searches is trivial and full-text searches aren't very fast in any relational database I've tried.
- Version control systems need to work on multiple platforms. This makes it harder to use a database that needs to be installed and running as a service (like MySQL or PostgreSQL).
- Version control systems on your local machine only need to be running when you're doing something (like a commit). Leaving a service like MySQL running all the time just in case you want to do a commit is wasteful.
- For the most part, version control systems never want to delete history, just append to it. That may lead to different optimizations, and different methods of protecting integrity.
Relational databases are safer
Again, why? You seem to assuming that because data is stored in files, version control systems like git and Mercurial don't have atomic commits, but they do. Relational databases also store their databases as files. It's notable here that CVS doesn't do atomic commits, but that's likely because it's from the dark ages, not because they don't use relational databases.
There's also the issue of protecting the data from corruption once it's in the database, and again the answer is the same. If the filesystem is corrupted, then it doesn't matter which database you're using. If the filesystem isn't corrupted, then your database engine might be broken. I don't see why a version control database would be more prone to this than a relational database.
I would argue that distributed version control systems (like git and Mercurial) are better for protecting your database than centralized version control, since you can restore the entire repo from any clone. So, if your central server spontaneously combusts, along with all of your backups, you can restore it by running
git init on the new server, then
git push from any developer's machine.
Reinventing the wheel is bad
Just because you can use a relational database for any storage problem doesn't mean you should. Why do you use configuration files instead of a relational database? Why store images on the filesystem when you could store the data in a relational database? Why keep your code on the filesystem when you could store it all in a relational database?
"If all you have is a hammer, everything looks like a nail."
There's also the fact that open-source projects can afford to reinvent the wheel whenever it's convenient, since you don't have the same kinds of resource constraints that commercial projects do. If you have a volunteer who's an expert at writing databases, then why not use them?
As for why we would trust the writers of revision control systems to know what they're doing.. I can't speak for other VCS's, but I'm pretty confident that Linus Torvalds understands filesystems.
Why do some commercial version control systems use a relational database then?
Most likely some combination of the following:
- Some developers don't want to write databases.
- Developers of commercial version control systems have time and resource constraints, so they can't afford to write a database when they have something close to what they want already. Also, developers are expensive, and database developers (as in, people who write databases) are probably more expensive, since most people don't have that kind of experience.
- Users of commercial version control systems are less likely to care about the overhead of setting up and running a relational database, since they already have one.
- Users of commercial version control systems are more likely to want a relational database backing their revision data, since this may integrate with their processes better (like backups for example).