Gil*_*tes 2 database git version-control mercurial
我找到了Linux Torvalds所说的邮件:
...和Monotone一起玩.真.他们使用"真实的数据库".
并开始感兴趣 - 为什么流行的VCS不使用数据库,并实现自己的数据存储模型来实现相同的目标 - 交易,耐用性等?
因为数据库通常具有针对与VCS系统大致相同的任务设计的存储和检索方法.使用特殊的方法来管理数据,为实现提供了一种能力,可以针对VCS系统的用例高度优化其代码. 虽然DVCS存储子系统的需求肯定会映射到"真实数据库"的关系模型,但为什么会这样呢?DVCS不需要正式查询(甚至更少需要SQL),而不是试图提示其数据库子系统的速度更快,它可能只是实现访问其管理的数据的最快和最安全的方法.
请注意,对Monotone的可怕速度的沮丧是Linus开始编写Git 的原因(他确实在BitMover从Linux开发人员的脚下拉下地毯之后首先考虑了现有的DVCS解决方案).并使用真实的数据库,另一个(较低可见)系统化石,并没有出色的表现(PDF)两种.
Git最初是作为一个实现版本化文件系统的最小工具集,其作者(Linus Torvalds)最初设想一个完整的VCS将是一个基于 Git 的工具.实际上,Git本身开始快速积累功能,使其成为一个成熟的VCS,因此虽然这些级别的某些分离仍然存在,但它们不是单独的项目.
关于Git存储子系统的另外两个有趣点:
最初它只是将其对象存储在单独的文件中.之后,它被教导透明地将最不频繁访问的对象的存储切换到所谓的"packfiles",这是一种压缩存档,具有用于快速遍历和访问的内置索引.
关键是开发人员研究了现有解决方案的性能,并仔细地改进了最能解决手头问题的改进措施.
它是被关于速度的提高.例如,在去年秋天已经讨论了另一堆加速Git指数(临时区域)的补丁.
关键在于,这些改进不仅仅是为了它们而编码,而是基于研究实际高工作负载的性能.
Mercurial采用与Git存储数据不同的方法,采用特殊的存储格式,便于使用差分数据.
因此,使用"真实数据库"的工具似乎可以分为以下广泛组:
"理想的设计".这是Monotone和Fossil.
据推测,此类工具的创建者认为使用"真实数据库"可以免费使用其中一个(例如耐久性).而这些好处是非常真实的(并且使用Sqlite进行存储会使备份变得简单).
虽然好处是真实的,但在其他VCS系统中实现自定义存储后端的代码确实提供了耐用性.请注意,虽然"真实数据库"采用巧妙的技巧来尝试确保它们存储的数据始终是正确和一致的,但不要做任何魔术:一切仍然归结为使用正确的文件操作顺序,fsync()等等.
"企业"的思维方式.例如,这就是Veracity,它至少声称支持其商业插件中的RDBMS后端.
企业通常已经投资了像Oracle或SQL Server这样的"大"数据库,或者像"高调"解决方案那样的管理.使用这种系统的好处在于它通常是专业管理的,提供细粒度的访问控制,备份等.
使用RDBMS的明显缺点是缺乏分布("DVCS"中缺少"D")以及失去设置的一般性.
从不同角度看自定义存储格式的奖励阅读:Keith Packard关于存储库格式为何重要的想法以及对Mercurial主要开发人员的一些观点的简短评论.
| 归档时间: |
|
| 查看次数: |
404 次 |
| 最近记录: |