仓库的定义

优质

小牛编辑

119浏览

2023-12-01

在进入与仓库管理有关的主题之前, 先给出仓库的定义. 它是什么样的? 感觉怎么样? 它喜欢喝热茶还是冰茶, 加不加糖或柠檬? 作为一名管理员, 人们期望你能同时从字面和系统层面理解仓库的组成—仓库看起来是什么样的, 被 Subversion 以外的工具操作时如何反应; 还要从逻辑层面理解在仓库内部数据是如何表示的.

如果站在文件浏览器 (例如 Windows 资源管理器) 或基于命令行的文件系统导航工具来看, Subversion 仓库只是一个包含了众多数据的普通目录, 其中一些子目录包含了人类可读的配置文件, 还有些子目录包含的是人类不可读的文件. 在设计 Subversion 时, 开发人员非常注意模块化与层次化, 因此简单地浏览一个典型仓库, 对于展示仓库的基本组件来说已经足够了.

$ ls repos
conf/  db/  format  hooks/  locks/  README.txt

下面是关于目录中的文件及其子目录的简单介绍. (不要拘泥于术语的具体意思—更详细的内容将在本章的其他地方进行介绍)

conf/: 存放配置文件的目录.
db/: 该目录包含了与所有版本化数据相关的数据. ^[46]
format: 该文件描述了仓库的内部组织结构. (目录 db/ 有时候也会有一个叫做 format 的文件, 这个 format 仅仅是在描述 db/ 的内容, 这两个 format 之间并没有关系.)
hooks/: 该目录包含了钩子脚本模板和已安装的钩子脚本.
locks/: Subversion 用该目录存放仓库的锁文件, 锁文件用于管理仓库的并发访问.
README.txt: 包含了一小段内容的文本文件, 文件的内容仅仅是为了提醒计算机用户该文件所在的目录是一个 Subversion 仓库.

注意

	注意
在 Subversion 1.5 之前, 仓库还有一个子目录 `dav`, `mod_dav_svn` 使用该目录存放与 WebDAV 活动 (activities)— 高层的 WebDAV 协议概念到 Subversion 提交事务的映射—有关的信息. Subversion 1.5 修改了这一行为, 它把活动目录的所有权和配置目录位置的能力移交给了 `mod_dav_svn`. 如今, 新的仓库不需要再保留子目录 `dav`, 除非 `mod_dav_svn` 正在被使用, 并且还没有把活动数据库存放位置设置到其他地方. 更多信息见 “mod_dav_svn 配置指令”一节

在 Subversion 1.5 之前, 仓库还有一个子目录 dav, mod_dav_svn 使用该目录存放与 WebDAV 活动 (activities)— 高层的 WebDAV 协议概念到 Subversion 提交事务的映射—有关的信息. Subversion 1.5 修改了这一行为, 它把活动目录的所有权和配置目录位置的能力移交给了 mod_dav_svn. 如今, 新的仓库不需要再保留子目录 dav, 除非 mod_dav_svn 正在被使用, 并且还没有把活动数据库存放位置设置到其他地方. 更多信息见 “mod_dav_svn 配置指令”一节

当然, 当我们通过 Subversion 库函数访问仓库时, 这些文件与目录就成为了一种虚拟的, 版本化的文件系统的实现, 并且搭配了可定制的事件触发器. 这个文件系统对文件和目录的概念都有自己的理解, 和真正的文件系统 (例如 NTFS, FAT32, ext3 等) 非常类似, 但它又比较特殊—它把文件和目录悬挂在版本号上, 安全地记录用户曾经对它们做出的修改, 并保证这些修改是永远可访问的. 这就是存放用户所有版本化数据的地方.

文件系统

在设计 Subversion 的开始阶段, 开发人员使用 Berkeley DB (BDB) 实现虚拟版本化文件系统的后端存储机制. 选择 Berkeley DB 基于多种理由, 包括它的开源授权, 事务支持, 可靠性, 高性能, 简单的 API, 线程安全, 支持游标等.

后来, 引入了新的后端存储机制—FSFS. ^[47] 这个所谓的 “文件系统的文件系统” 并不是一个在不透明的数据库容器中实现的版本化文件系统, 而是一个由大量文件组成的集合, 这些文件更加透明, 存放在操作系统的文件系统中. 随着软件的成熟, FSFS 最终成为了 Subversion 默认的后端存储机制. FSFS 并没有因此停止前进的脚步, 后来, 几乎在每一项指标上—从性能, 到可扩展性, 再到可靠性 —FSFS 都超越了 Berkeley DB.

如今, 如果用户使用的是开源的 Subversion 产品, 那么一般情况下使用 FSFS 作为仓库的后端存储. 实际上从 Subversion 1.8 开始, 官方不再推荐使用 Berkeley DB 作为仓库的后端存储, 仍然使用 Berkeley DB 的仓库在新版的 Subversion 1.x 下可以继续工作, 但与 Berkeley DB 相关的开发工作不再继续—包括新特性或扩展. Subversion 只想提供一种单一的仓库后端存储机制, 而 FSFS 赢得了青睐.

必要时, 本书仍然会介绍如何管理基于 BDB 的仓库, 但本章的大部分内容假设仓库后端存储用的是 FSFS. 关于如何管理基于 BDB 仓库的更完整的信息, 请参考附录 D, 传统的 Berkeley DB 后端存储 或本书的旧版.

^[46]严格地讲, Subversion 并没有强制要求版本化数据一定要存放在该目录内, 还存在一些其他的后端存储实现 (尽管是有专利的) 不把数据存放在该目录内.

^[47]虽然经常被读作 “fuzz-fuzz”, 但本书假定读者把它念作 “eff-ess-eff-ess”.