Berkeley DB 环境不可移植。您不能简单地将一个在 Unix 系统上创建的 Subversion 仓库复制到 Windows 系统，并期望它能正常工作。虽然 Berkeley DB 数据库格式的大部分是独立于架构的，但环境的其他方面却并非如此。

其次，Subversion 需要使用 Berkeley DB 的一种在 Windows 95/98 系统上无法运行的方式 - 如果您需要在 Windows 机器上存放一个 BDB 支持的仓库，请使用 Windows 2000 或更高版本。

虽然 Berkeley DB 承诺在满足特定规范集的网络共享上正常运行，^[88] 但大多数网络文件系统类型和设备实际上并不满足这些要求。在任何情况下，您都不能允许位于网络共享上的 BDB 支持的仓库被该共享的多个客户端同时访问（这往往是将仓库置于网络共享上的主要目的）。

	警告
	如果您尝试在不兼容的远程文件系统上使用 Berkeley DB，结果是不可预测的 - 您可能会立即看到神秘的错误，或者可能要过几个月才能发现您的仓库数据库已 subtly 损坏。对于需要存放在网络共享上的仓库，您应该强烈考虑使用 FSFS 数据存储。

由于 Berkeley DB 是直接链接到 Subversion 的库，因此它比典型的关系数据库系统对中断更敏感。例如，大多数 SQL 系统都有一个专用的服务器进程来调解对表的所有访问。如果访问数据库的程序由于某种原因崩溃，数据库守护进程会注意到连接丢失并清理任何遗留的混乱。由于数据库守护进程是唯一访问表的进程，因此应用程序不必担心权限冲突。

然而，对于 Berkeley DB 来说情况并非如此。Subversion（以及使用 Subversion 库的程序）直接访问数据库表，这意味着程序崩溃可能会使数据库处于暂时不一致、不可访问的状态。当这种情况发生时，管理员需要要求 Berkeley DB 恢复到检查点，这有点令人讨厌。除了崩溃的进程外，其他事情也会导致仓库“卡住”，例如程序在数据库文件的所有权和权限方面发生冲突。

	注意
	Berkeley DB 4.4（针对 Subversion 1.4 及更高版本）为 Subversion 带来了自动透明地恢复需要恢复的 Berkeley DB 环境的功能。当 Subversion 进程连接到仓库的 Berkeley DB 环境时，它使用一些进程会计机制来检测先前进程的任何不正常断开连接，执行必要的恢复，然后继续运行，就好像什么也没发生一样。这并不能完全消除仓库卡住的情况，但确实大大减少了从这些情况中恢复所需的人工干预。