Fossil SCM 2.28 介绍与选型指南

定位：Fossil 是 SQLite 作者 D. Richard Hipp 发起的分布式版本控制系统（DVCS），把版本控制、Wiki、工单、论坛、聊天、内嵌文档、技术笔记与细粒度 RBAC 全部装进一个可执行文件 + 一个 SQLite 仓库文件里，官方自称"GitHub-in-a-box"。本文是认知与选型篇，结论全部来自 2026-10-27 对官方站点、官方文档与上游发布页的联网溯源，不含本机实测；安装、配置与命令的实测结论见本专栏另外三篇。

1. 版本与交付形态：先看一个数字

截至 2026-10-27，fossil-scm.org 首页标注的最新正式版为 2.28，发布日期 2026-03-11。官网自身运行的是 2.29 开发版（构建号 0d2ceb89e1，2026-10-24），说明 2.28 之后主干仍在活跃提交，但对外可用的稳定标签仍是 2.28。

官方 Linux x86_64 发布包 fossil-linux-x64-2.28.tar.gz 的 Content-Length 为 4,110,148 字节（约 3.9 MiB）。解包后就是一个静态链接程度很高的单一 fossil 可执行文件，没有 Python、Java、Node、外部数据库或 Web 服务器依赖——这是它区别于几乎所有同类方案的第一性特征。

作为对照，同期 Gitea 最新版 28.2.0（2026-10-18） 的 gitea-28.2.0-linux-amd64 原始二进制为 114.0 MB，并且仍要求宿主机预装 Git 才能提供版本控制能力。两者不是同一层面的产品，但"要在一台机器上得到一个可用的代码协作站点，需要交付多少东西"这个问题的答案，差距接近两个数量级。

2. 单文件仓库架构：为什么备份只需要 cp

Fossil 的官方文件格式文档把仓库定义为一组无序的 artifact（工件）集合，每个 artifact 以其原始内容的哈希命名，当前支持 SHA1 与 SHA3-256，且同一仓库内可以混用。artifact 分两类：

• 内容工件：被纳入版本管理的源码文件、Wiki 正文、工单描述等原始内容；
• 结构工件：按特殊格式描述其他工件关系的清单，例如一次检入（check-in）的 manifest，记录本次包含哪些文件、各文件对应哪个 blob、父检入是谁、提交说明是什么。

这些 artifact 加上索引关系，全部落在一个 SQLite 数据库文件里（典型表包括 blob、delta、event、mlink、plink、tagxref 等）。因此一个 project.fossil 文件既是"版本库"，也是"Wiki 库 + 工单库 + 论坛库 + 用户与权限库"。这带来三个直接后果：

1. 备份粒度是文件级：停写后复制单个文件，或用 fossil backup 生成一致性副本，就完成了全量备份，不存在"代码在 Git 目录、Issue 在 MySQL、附件在对象存储"的三处对账问题。
2. 克隆即全量协作数据：fossil clone 拉下来的不只是历史提交，还包括 Wiki、工单、论坛帖与附件。离线在飞机上改代码、写工单、补 Wiki，落地后 fossil sync 一次性推回。
3. 仓库是自描述且长期可读的：官方明确以"几十年到上百年后仍可被未出生的人读取、搜索、扩展"为设计目标，格式文档本身公开，SQLite 又是世界上部署量最大的数据库之一，降低了"考古式恢复"的风险。

需要区分的是全局状态与本地状态：全局状态（artifact 集合）在克隆间同步；本地状态（Web 皮肤、用户账号、工单报表格式、订阅配置等）保存在仓库内的本地表中，不参与同步，各副本可以不同。这一点在规划多站点镜像时很关键——外观与账号策略不会互相覆盖。

3. 内建协作面：一个进程就是一套 forge

Fossil 官方与 Git 的对比文档用一张表概括了能力边界：Git 只做文件版本管理，而 Fossil 内置 tickets、wiki、docs、notes、forum、chat、Web UI 与 RBAC。这些在 Git 世界需要 Gitea/GitLab/Forgejo 等第三方 forge 补齐，在 Fossil 里是同一份代码、同一个仓库、同一个进程。

具体可用面：

• Timeline（时间线）：把检入、工单变更、Wiki 编辑、论坛发帖、标签事件合并成一条按时间排序的项目动态流，可按类型过滤。这是 Fossil 日常使用频率最高的页面。
• Ticket（工单）：内置工单系统，支持自定义字段、状态流转、报表格式（reportfmt）与查询语句，不依赖外部 issue tracker。
• Wiki 与内嵌文档：Wiki 页面本身是版本化 artifact，可 diff、可回溯；/doc 目录下的 Markdown/Wiki 文档随代码一起发布。
• Forum 与 Chat：论坛帖子入库并可离线同步；Chat 提供项目内即时讨论。
• Technotes（技术笔记）：不进入代码树、但可在时间线与 Web 上查看的轻量记录，适合决策日志。
• RBAC：按用户/能力（读、写、建工单、审帖、管理）授权，支持 default-permissions、匿名访问与自注册验证码等策略。
• Web 服务：fossil server 直接提供 HTTP 服务，另有 SCGI/CGI 模式可挂在 Nginx/Apache 后面；同一套 UI 还负责 HTTP 克隆与同步（xfer 协议）。

也就是说，选 Fossil 不是"选一个 Git 的替代 CLI"，而是"选一个自带 forge 的协作内核"。这会显著改变运维模型：不需要再维护"Git 服务 + 数据库 + Web 前端 + 缓存 + 任务队列"这一串进程。

4. 与 Git+Gitea、Mercurial、Darcs、Sourcehut 的量化对比

下表把"自建一套代码协作服务"作为统一比较场景，数据来自各项目官方站点/文档与上游发布页（查询日期 2026-10-27）：

维度	Fossil 2.28	Git + Gitea 28.2.0	Mercurial 7.2	Darcs 2.18.5	Sourcehut
交付形态	单一可执行文件，发布包约 3.9 MiB	Git CLI + Gitea 二进制 114.0 MB	Python 实现，需 Python 运行时	单一 Haskell 二进制	多个 mini-service（Go API + Python 前端）
外部依赖	基本无（libc 级）	必须预装 Git；数据库可选 SQLite/MySQL/PostgreSQL	Python 3 及依赖	运行时随二进制分发	PostgreSQL（每服务一库）、Redis 兼容存储、邮件服务器、Nginx
仓库布局	单个 SQLite 文件	.git 对象库 + 独立 forge 数据库	.hg 目录（revlog）	_darcs 补丁集合	Git/Hg 仓库 + 各服务元数据
内建 forge	Wiki/工单/论坛/聊天/文档/笔记/RBAC/时间线	由 Gitea 提供（独立进程）	hg serve/hgweb 仅浏览，无工单/Wiki	无	有（git/hg/lists/builds/todo 等）
Web 托管	fossil server 内建 HTTP，另支持 SCGI/CGI	Gitea 内建 HTTP，常配 Nginx 反代	hg serve 内建只读服务	无内建服务	各服务独立端口，统一反代
全量备份	复制单文件 / fossil backup	数据库 dump + 仓库目录 + 配置 + 附件	复制 .hg 或 hg bundle	复制 _darcs	PostgreSQL dump + 多服务数据目录
离线能力	代码+Wiki+工单+论坛全量离线	代码可离线，forge 数据不可离线	代码全量离线	代码全量离线	依赖在线服务
变更模型	快照式检入 + 内容寻址 artifact	快照式提交（DAG）	快照式 revlog + revset	补丁理论（patch 交换）	取决于底层 Git/Hg
典型部署面	1 个进程 + 1 个文件	2 个以上进程 + 数据库 + 仓库目录	1 个进程 + 目录	纯命令行	5 个以上服务 + 数据库 + 缓存 + MTA
学习曲线	命令集小，概念少	Git 概念多 + forge 运维	中等，revset 较强	概念独特，生态小	运维复杂度最高

4.1 对 Git + Gitea

Git 的优势不在本文讨论范围（生态、IDE 集成、CI 市场、托管平台互操作），但要看清代价：Gitea 二进制 114 MB 只是起点，实际运行还需要外部 Git、数据库（可用内嵌 SQLite 驱动）、仓库存储目录、附件目录与配置目录；升级时要同时处理二进制、配置迁移与数据库迁移。Fossil 的升级动作是把新二进制替换旧文件，仓库文件格式向后兼容，通常无需迁移步骤。

功能层面两者高度重叠（仓库浏览、Issue、Wiki、PR/代码评审）。差异在于：Gitea 的 Issue/Wiki 存在数据库里，与 Git 仓库分离；Fossil 的工单/Wiki 是仓库 artifact，随 clone/sync 走。对于"要把项目完整状态打包带走/归档"的场景，Fossil 的单文件模型明显更省心。

4.2 对 Mercurial 7.2

Mercurial 7.2 发布于 2026-01-29，是成熟的 Python DVCS，hg serve 提供内建 Web 浏览与 HTTP 拉取，但没有内建工单、Wiki、论坛；要得到 forge 能力仍需外挂（如 Sourcehut 的 hg 支持或自建服务）。Mercurial 的 revset 查询语言与扩展生态强于 Fossil，适合习惯 Python 工具链、需要复杂历史查询的团队。运维上它依赖 Python 运行时，交付不如单二进制干净。

4.3 对 Darcs 2.18.5

Darcs 2.18.5 以补丁（patch）而非快照为核心，交互式记录、离线工作、无需中心服务器是其卖点，官方也强调"比 Git/Mercurial/SVN 更自由的变更模型"。但 Darcs 没有内建 Web 服务与 forge，仓库是 _darcs 补丁集合，社区与生态规模远小于前三者。它适合个人或极小团队做补丁交换，不适合需要浏览、工单、权限体系的项目站点。

4.4 对 Sourcehut

Sourcehut 官方安装文档明确说明它是一个由 mini-service 组成的分布式系统（git、builds、todo 等），唯一必需的是 meta.sr.ht（账号与认证）；前置依赖包括 PostgreSQL（每个服务一个数据库）、Redis 兼容键值存储（生产用 Redict）、邮件服务器与 Nginx。它的功能面最接近"完整 forge + CI + 邮件列表"，但自建门槛与组件数量也最高。Fossil 用 1 个进程覆盖了 Sourcehut 中 git+todo+lists 的一部分能力，代价是没有独立的 CI 编排与邮件列表工作流。

注：Sourcehut 文档提到的社区快速搭建环境涉及编排工具，本文只用其官方组件清单做对比，不展开部署方式。

5. 量化结论：三条可验证的差距

1. 交付体积：Fossil 3.9 MiB 发布包 vs Gitea 114.0 MB 二进制，约 29 倍；若计入外部 Git、数据库与前端资产，实际部署体积差距更大。
2. 组件数量：Fossil 1 个进程 vs Gitea 至少 2 个（Gitea + 外部 Git 调用）vs Sourcehut 5 个以上服务加 3 类基础设施（数据库、缓存、邮件）。
3. 备份对象数量：Fossil 1 个文件 vs Gitea 至少 4 类（数据库、仓库、附件、配置）vs Sourcehut 每个服务的数据库加数据目录。

这三条不是"谁更先进"，而是"运维表面积"的直接度量。团队越小、环境越封闭、生命周期越长，Fossil 的收益越明显。

6. 适用与不适用场景

建议选 Fossil：

• 离线优先/内网隔离：现场交付、军工/工业内网、海上/野外作业，需要把代码、文档、工单一起带走并双向同步。
• 小团队（约 1–20 人）：不需要专职平台运维，一个人就能完成升级、备份、迁移。
• 单二进制运维：目标机不允许装 Python/Java/数据库，或希望把整个 forge 塞进一个目录。
• 长周期归档：项目要保存十年以上，重视格式公开、单文件可读、工具链极简。
• 嵌入式/边缘设备：资源受限但需要版本控制与轻量 Web 浏览。
• 教学与个人项目：概念少、一条命令起服务，适合讲清 DVCS 与 forge 的关系。

不建议选 Fossil：

• 超大规模单体仓库：Linux 内核级别的提交量、分支数与并发克隆，Git 的生态与性能工程更成熟。
• 强依赖 GitHub/GitLab 生态：Actions、LFS、PR 工作流、IDE 深度集成、代码扫描市场，迁移成本大于收益。
• 大型多团队组织的权限与审计：需要 SSO、细粒度组织架构、审计日志集中化时，成熟 forge 更合适。
• 需要成熟 CI/CD 编排：Fossil 不提供现代流水线编排，仍需外部 CI。
• 必须用 Merge/Pull Request 评审模型：Fossil 的代码评审以分支/工单/论坛组合实现，与 PR 心智模型不同。

7. 选型决策清单

按顺序回答下面 6 个问题，任一为"是"就应认真考虑 Fossil：

1. 是否要求代码、Wiki、工单、论坛能一起离线并双向同步？
2. 是否希望备份只处理一个文件？
3. 目标环境是否不允许安装 Python/Java/外部数据库？
4. 团队规模是否在 20 人以内、无专职平台运维？
5. 项目生命周期是否超过 5 年、重视格式长期可读？
6. 是否接受用工单+分支+论坛替代 PR 评审流程？

反之，如果第 1–6 全部为"否"，且强依赖现代 forge 生态与 CI，继续使用 Git + Gitea/GitLab 更稳妥。

8. 站内延伸阅读

• 部署落地：本专栏《Ubuntu 22.04 安装 Fossil SCM 2.28 指南》覆盖官方二进制/apt/源码三条路线、systemd 托管 fossil server、Nginx 反代与 SCGI、HTTPS、备份与排障实录。
• 参数调优：本专栏《Fossil SCM 2.28 配置参数详解》逐项拆解 fossil settings、仓库级配置与 fossil all 批量管理。
• 命令实战：本专栏《Fossil SCM 2.28 常用 CLI 命令详解》给出 init/clone/sync/commit/branch/merge/rebuild 等命令的真实回显与解读。

9. 参考来源（查询日期 2026-10-27）

1. Fossil 官方首页（最新正式版 2.28，2026-03-11；站点运行 2.29 开发版）：https://fossil-scm.org/home/
2. Fossil 官方文件格式文档（artifact、SHA1/SHA3-256、全局/本地状态）：https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki
3. Fossil 官方《Fossil Versus Git》（能力对比表：tickets/wiki/docs/notes/forum/chat/UI/RBAC）：https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki
4. Fossil 官方 Linux x64 2.28 发布包（HTTP Content-Length: 4110148）：https://fossil-scm.org/home/uv/fossil-linux-x64-2.28.tar.gz
5. Fossil 官方发布历史（version-2.28 标签）：https://fossil-scm.org/home/timeline?t=release
6. Gitea 官方文档《Installation from binary》（内嵌 SQLite/MySQL/PostgreSQL 支持）：https://docs.gitea.com/installation/install-from-binary
7. Gitea 上游发布页（28.2.0，2026-10-18；linux-amd64 资产 114.0 MB）：https://github.com/go-gitea/gitea/releases
8. Mercurial 官方站点（7.2，2026-01-29）：https://www.mercurial-scm.org/
9. Darcs 官方站点（最新版 2.18.5，补丁模型与离线特性）：https://darcs.net/
10. Sourcehut 官方安装文档（mini-service 架构、PostgreSQL/Redis/邮件/Nginx 前置依赖）：https://man.sr.ht/installation.md
11. Sourcehut 官方首页（工具套件与无 JavaScript/无跟踪定位）：https://sourcehut.org/