版本库数据存储
在Subversion1.2中，版本库中存储数据有两种方式。一种是在Berkeley DB数据库中存储数据；另一种是使用普通的文件，使用自定义格式。因为Subversion的开发者称版本库为（版本化的）文件系统，他们接受了称后一种存储方式为FSFS[]的习惯，也就是说，使用本地操作系统文件系统来存储数据的版本化文件的系统。
建 立一个版本库时，管理员必须决定使用Berkeley DB还是FSFS。它们各有优缺点，我们将详细描述。这两个中并没有一个是更正式的，访问版本库的程序与采用哪一种实现方式无关。访问程序并不知道版本库 如何存储数据，它们只是从版本库的API读取到修订版本和事务树。
从总体上比较了Berkeley DB和FSFS版本库，下一部分将会详细讲述细节。
表 5.1. 版本库数据存储对照表
| 特性 | Berkeley DB | FSFS |
|---|---|---|
| 对操作中断的敏感 | 很敏感；系统崩溃或者权限问题会导致数据库“塞住”，需要定期进行恢复。 | 不敏感。 |
| 可只读加载 | 不能 | 可以 |
| 存储平台无关 | 不能 | 可以 |
| 可从网络文件系统访问 | 不能 | 可以 |
| 版本库大小 | 稍大 | 稍小 |
| 可扩展性：修订版本树的数量 | 数据库，没有限制 | 许多古老的本地文件系统在处理单一目录包含上千个条目时出现问题。 |
| 可扩展性：文件较多的目录 | 较慢 | 较快 |
| 速度：检出最新的代码 | 较快 | 较慢 |
| 速度： 大的提交 | 较慢，但是时间被分配在整个提交操作中 | 较快，但是最后较长的延时可能会导致客户端操作超时 |
| 组访问权处理 | 对于用户的umask设置十分敏感，最好只由一个用户访问。 | 对umask设置不敏感 |
| 功能成熟时间 | 2001年开始使用 | 2004年开始使用 |
Berkeley DB
在Subversion的初始设计阶段，开发者因为多种原因而决定采用Berkeley DB，比如它的开源协议、事务支持、可靠性、性能、简单的API、线程安全、支持游标等。
Berkeley DB提供了真正的事务支持－这或许是它最强大的特性，访问你的Subversion版本库的多个进程不必担心偶尔会破坏其他进程的数据。事务系统提供的隔 离对于任何给定的操作，Subversion版本库代码看到的只是数据库的静态视图－而不是一个在其他进程影响不断变化的数据库－并能够根据该视图作出决 定。如果该决定正好同其他进程所做操作冲突，整个操作会回滚，就像什么都没有发生一样，并且Subversion会优雅的再次对更新的静态视图进行操作。
Berkeley DB另一个强大的特性是热备份－不必“脱机”就可以备份数据库环境的能力。我们将会在讨论如何备份你的版本库，能够不停止系统对版本库做全面备份的好处是显而易见的。
Berkeley DB同时是一个可信赖的数据库系统。Subversion利用了Berkeley DB可以记日志的便利，这意味着数据库先在磁盘上写一个日志文件，描述它将要做的修改，然后再做这些修改。这是为了确保如果如果任何地方出了差错，数据库 系统能恢复到先前的检查点—一个日志文件认为没有错误的位置，重新开始事务直到数据恢复为一个可用的状态。关于Berkeley DB日志文件的更多信息请查看。
但 是每朵玫瑰都有刺，我们也必须记录一些Berkeley DB已知的缺陷。首先，Berkeley DB环境不是跨平台的。你不能简单的拷贝一个在Unix上创建的Subversion版本库到一个Windows系统并期望它能够正常工作。尽管 Berkeley DB数据库的大部分格式是不受架构约束的，但环境还是有一些方面没有独立出来。其次，使用Berkeley DB的Subversion不能在95/98系统上运行—如果你需要将版本库建在一个Windows机器上，请装到Windows2000或 WindowsXP上。另外，Berkeley DB版本库不能放在网络共享文件夹中，尽管Berkeley DB承诺如果按照一套特定规范的话，可以在网络共享上正常运行，但实际上已知的共享类型几乎都不满足这套规范。
最后，因为Berkeley DB的库直接链接到了Subversion中，它对于中断比典型的关系型数据库系统更为敏感。大多数SQL系统，举例来说，有一个主服务进程来协调对数据 库表的访问。如果一个访问数据库的程序因为某种原因出现问题，数据库守护进程察觉到连接中断会做一些清理。因为数据库守护进程是唯一访问数据库表的进程， 应用程序不需要担心访问许可的冲突。但是，这些情况与Berkeley DB不同。Subversion（和使用Subversion库的程序）直接访问数据库的表，这意味着如果有一个程序崩溃，就会使数据库处于一个暂时的不 一致、不可访问的状态。当这种情况发生时，管理员需要让Berkeley DB恢复到一个检查点，这的确有点讨厌。除了崩溃的进程，还有一些情况能让版本库出现异常，比如程序在数据库文件的所有权或访问权限上发生冲突。因为 Berkeley DB版本库非常快，并且可以扩展，非常适合使用一个单独的服务进程，通过一个用户来访问—比如Apache的httpd或svnserve（参见）—而不是多用户通过file:///或svn+ssh://URL的方式多用户访问。如果将Berkeley DB版本库直接用作多用户访问，请先阅读。
FSFS
在 2004年中期，另一种版本库存储系统慢慢形成了：一种不需要数据库的存储系统。FSFS版本库在单一文件中存储修订版本树，所以版本库中所有的修订版本 都在一个子文件夹中有限的几个文件里。事务在单独的子目录中被创建，创建完成后，一个单独的事务文件被创建并移动到修订版本目录，这保证提交是原子性的。 因为一个修订版本文件是持久不可改变的，版本库也可以做到热备份，就象Berkeley DB版本库一样。
修订版本文件格式代表了一个修订 版本的目录结构，文件内容，和其它修订版本树中相关信息。不像Berkeley DB数据库，这种存储格式可跨平台并且与CPU架构无关。因为没有日志或用到共享内存的文件，数据库能被网络文件系统安全的访问和在只读环境下检查。缺少 数据库花消同时也意味着版本库的总体体积可以稍小一点。
FSFS也有一种不同的性能特性。当提交大量文件时，FSFS使用O(N)算法来追 加条目，而Berkeley DB则用(N^2)算法来重写整个目录。另一方面，FSFS通过写入与上一个版本比较的变化来记录新版本，这也意味着获取最新修订版本时会比 Berkeley DB慢一点，提交时FSFS也会有一个更长的延迟，在某些极端情况下会导致客护端在等待回应时超时。
最重要的区别是当出现错误时FSFS不会楔住的能力。如果使用Berkeley DB的进程发生许可错误或突然崩溃，数据库会一直无法使用，直到管理员恢复。假如在应用FSFS版本库时发生同样的情况，版本库不会受到任何干扰，最坏情况下也就是会留下一些事务数据。
唯一真正对FSFS不利的是相对于Berkeley DB的不成熟，缺乏足够的使用和压力测试，许多关于速度和可扩展性的判断都是建立在良好的猜测之上。在理论上，它承诺会降低管理员新手的门槛并且更加不容易发生问题。在实践中，只有时间可以证明。
转自：http://www.blogjava.net/jasmine214--love/archive/2011/01/18/343160.html