Berkeley DB 环境是不可移植的. 管理员不能简单地把在 Unix 系统中 创建的 Subversion 仓库复制到 Windows 系统中, 然后希望它能照常工作. 虽然 Berkeley DB 数据库格式的大部分都是体系结构无关的, 但仍然存在 与体系结构相关的部分.

第二, Subversion 使用 Berkeley DB 的方式在 Windows 95/98 中 无法工作—如果管理员要在 Windows 系统中创建基于 BDB 的 Subversion 仓库, 必须是 Windows 2000 或更新的版本.

虽然 Berkeley DB 声称对于满足特定规范的网络共享目录 ^[84], 它可以正常工作, 但大部分网络文件系统和应用程序 其实并 不满足 这些规范. 另外, 位于网络共享目录 内的, 基于 BDB 的 Subversion 不允许多个客户端同时访问 (而这却是把 仓库放在共享目录后无法避免的问题).

	警告
	如果管理员试图在一个不兼容的远程文件系统中使用 Berkeley DB, 结果将是无法预测的—管理员可能会马上看到诡异的错误, 或者是 直到几个月后才发现仓库的数据库已经产生了细微的损坏. 强烈建议在 网络共享目录中使用基于 FSFS 的 Subversion 仓库.

由于 Berkeley DB 的库函数被静态地链接到 Subversion 中, 所以和 典型的关系数据库系统相比, Berkeley DB 对中断更加敏感. 例如大多数 SQL 系统都有一个专用的服务器进程, 负责协调对数据库表的所有访问, 如果正在 访问数据库的程序崩溃了, 数据库守护进程将会注意到断开的连接, 并清理留下 的任何杂物. 由于数据库守护进程是访问数据库表的唯一一个进程, 应用程序不 用再担心权限冲突.

然而, Berkeley DB 没有专用的进程负责协调对数据库表的访问, Subversion (和使用了 Subversion 库函数的程序) 是直接访问数据库表, 这就意味着如果程序崩溃, 数据库将临时地处于一种不一致和不可访问的状态. 如果发生了这种情况, 管理员需要请求 Berkeley DB 恢复到一个检查点, 实际做起来会有点麻烦. 除了程序崩溃, 还有些情况会造成仓库 “卡住”, 例如程序的所有者权限与数据库文件的权限相冲突.

	注意
	Berkeley DB 4.4 为 Subversion (1.4 或更新的版本) 带来了自动 恢复 Berkeley DB 环境的能力. 当一个 Subversion 进程附加到仓库 的 Berkeley DB 环境上时, 它将使用进程记账机制来检测前一个进程 留下的未清理的连接, 执行必要的恢复操作, 然后继续往下执行, 就好像 什么事都没发生过. 虽然这不能完全避免仓库卡住的情况出现, 但还是 大大减少了恢复所需的人工介入.