您似乎在做出许多假设,可能是基于您对SVN和CVS的经验。
Git和Mercurial基本上就像SVN和CVS
比较git和CVS就像比较iPad和Atari。CVS是在恐龙漫游地球时创建的。Subversion基本上是CVS的改进版本。假设像git和Mercurial这样的现代版本控制系统像它们那样工作几乎没有任何意义。
关系数据库比单一用途的数据库效率更高
为什么?关系数据库确实非常复杂,并且可能没有单一用途的数据库有效。我的脑海有些变化:
- 版本控制系统不需要复杂的锁定,因为无论如何您不能同时进行多个提交。
- 分布式版本控制系统需要非常节省空间,因为本地数据库是仓库的完整副本。
- 版本控制系统只需要以几种特定的方式查找数据(按作者,按修订ID,有时是全文搜索)。创建自己的数据库来处理作者/修订ID搜索很简单,在我尝试过的任何关系数据库中,全文搜索都不是很快。
- 版本控制系统需要在多个平台上工作。这使得使用需要安装并作为服务运行的数据库(例如MySQL或PostgreSQL)更加困难。
- 本地计算机上的版本控制系统仅在执行某些操作(例如提交)时才需要运行。离开运行像MySQL服务所有的时间,以防万一你想要做一个承诺是一种浪费。
- 在大多数情况下,版本控制系统从不希望删除历史记录,而只是将其追加。这可能导致不同的优化和保护完整性的不同方法。
关系数据库更安全
同样,为什么呢?您似乎以为,因为数据存储在文件中,所以git和Mercurial之类的版本控制系统没有原子提交,但它们确实有原子提交。关系数据库也其数据库存储为文件。这里值得注意的是CVS 不会执行原子提交,但这很可能是因为它来自黑暗时代,而不是因为它们不使用关系数据库。
一旦将数据放入数据库中,还存在防止数据损坏的问题,答案也相同。如果文件系统已损坏,则使用哪个数据库都没有关系。如果文件系统未损坏,则数据库引擎可能已损坏。我不明白为什么版本控制数据库比关系数据库更容易出现这种情况。
我认为,分布式版本控制系统(如git和Mercurial)比集中式版本控制更适合保护数据库,因为您可以从任何克隆还原整个存储库。因此,如果中央服务器与所有备份一起自然燃烧,则可以通过git init
在新服务器上运行来恢复它,然后git push
从任何开发人员的计算机上恢复它。
重新发明轮子是不好的
仅仅因为您可以将关系数据库用于任何存储问题,并不意味着您应该这样做。为什么使用配置文件而不是关系数据库?当您可以将数据存储在关系数据库中时,为什么将图像存储在文件系统上?当您可以将所有代码存储在关系数据库中时,为什么还要将代码保留在文件系统上?
“如果你只有一把锤子,那么一切看起来就像钉子。”
还有一个事实是,开源项目有能力在方便的时候重新发明轮子,因为您没有商业项目那样的资源约束。如果您有一位自愿编写数据库的志愿者,那么为什么不使用它们呢?
至于为什么我们希望版本控制系统的作者知道他们在做什么。.我不能代表其他VCS,但是我非常有信心Linus Torvalds可以 理解文件系统。
为什么某些商业版本控制系统使用关系数据库呢?
最有可能是以下各项的组合:
- 一些开发者不想要编写数据库。
- 商业版本控制系统的开发人员受时间和资源的限制,因此,当他们拥有的东西已经接近他们想要的东西时,他们将无力编写数据库。而且,开发人员很昂贵,而数据库开发人员(例如,编写数据库的人)可能会更昂贵,因为大多数人没有那种经验。
- 商业版本控制系统的用户不太可能关心建立和运行关系数据库的开销,因为他们已经拥有一个。
- 商业版本控制系统的用户更可能希望使用关系数据库来支持其修订数据,因为这可以更好地与他们的流程集成(例如备份)。