Subversion的FSFS后端（FSDATA）是专有二进制格式，无公开稳定API，官方不保证磁盘格式向后兼容；直接解析db/revs/等文件风险极高，易因压缩、编码、事务标记等导致崩溃或数据错乱；唯一安全方式是通过libsvn_repos等C API间接访问，并严格管理内存池生命周期。
Subversion的FSDATA不是标准可读格式，直接解析风险极高
Subversion的fsfs后端（即FSDATA所在格式）是专有二进制存储结构，没有公开、稳定、向后兼容的API供外部程序直接读取。官方明确不承诺其磁盘格式稳定性——哪怕同一主版本的小更新（如1.14.0 → 1.14.1）都可能静默变更布局。试图用fread或mmap硬解析db/revs/或db/revprops/下的文件，大概率在升级SVN后立即失效，且极易因未处理压缩（zlib）、自定义编码（svn_fs_fs__rep_header_t）、事务隔离标记等问题导致内存越界或数据错乱。
必须通过libsvn_fs_fs或libsvn_repos的C API间接访问
Subversion自身所有工具（svnadmin, svnlook）都走这套路径。C++项目若需读取仓库元数据或版本内容，唯一安全方式是链接libsvn_repos并调用其封装函数：
-
svn_repos_open2()打开仓库（传入db/父目录路径，不是db/本身） -
svn_repos_fs_begin_txn_for_commit2()或svn_repos_fs_revision_root()获取指定修订版的只读根节点 -
svn_fs_file_contents()读取某路径下文件内容（返回svn_stream_t*，需用svn_stream_read_full()消费） -
svn_fs_node_created_rev()、svn_fs_node_prop()等获取属性和时间戳
注意：这些API要求你初始化Subversion运行时环境（svn_cmdline_init() 或手动调用 svn_fs_initialize()），且所有svn_*_t*指针必须用对应svn_pool_t*管理生命周期——漏掉svn_pool_destroy()会导致严重内存泄漏。
常见错误：把FSDATA当普通文件系统处理
开发者常误以为db/revs/123是纯文本或可grep的log，实际它是混合了增量差异（fulltext或delta）、base64编码、长度前缀、校验头的二进制块。典型翻车点包括：
立即学习“C++免费学习笔记（深入）”；
- 直接
std::ifstream读取db/revs/123并尝试std::string::find("Author:")→ 找不到，因为作者信息存在db/revprops/123，且值经过svn_stringbuf_serialize()序列化 - 用
zlib解压db/revs/123失败 → 因为只有部分revision使用压缩，且头部有2字节magic（0x8b1f仅当启用compress-revprops时才出现），需先解析FSFS header - 跳过
db/transactions/目录认为它“无关” → 错，未提交事务可能包含正在编辑的最新状态，svnlook youngest会忽略它们，但业务逻辑若需实时性就得处理
替代方案：用svnlook命令行+管道更简单可靠
若C++程序只是需要轻量级读取（比如CI中检查提交作者、变更文件列表），直接调用svnlook比链接libsvn更省事，也规避ABI绑定风险：
// 示例：获取r123修改的C++文件列表 std::string cmd = "svnlook changed -r 123 /path/to/repo | grep '\.cpp$'"; FILE* pipe = popen(cmd.c_str(), "r"); // ... fgets读取结果 pclose(pipe);
注意：确保svnlook版本与仓库格式兼容（如FSFS v8仓库需SVN ≥ 1.10），且执行用户对仓库目录有读权限（尤其db/子目录）。临时文件描述符泄漏、信号中断（SIGPIPE）和空输出边界条件仍需手工处理。
真正棘手的是跨修订版的增量分析或实现类似svnsync的同步逻辑——这时没法绕开libsvn，必须接受它沉重的依赖和晦涩的pool内存模型。
