版本控制系统：PRCS与Historian的深度解析

# 版本控制系统：PRCS与Historian的深度解析 ## 1. PRCS系统解析 ### 1.1 子项目管理 PRCS（The Project Revision Control System）没有专门用于管理子项目的明确工具。不过，可以通过在超级项目包含的文件中加入子项目的版本描述文件，以一种简约的方式达到类似效果。具体操作流程如下： 1. 提交超级项目时，先提交子项目（如有需要），再提交超级项目。 2. 检出该版本时，会获取子项目描述文件，这些文件能唯一标识子项目的版本。 3. 根据描述文件检出子项目（在PRCS中是简单操作）即可恢复子项目。 目前还不清楚这种简单的递归过程是否足够常见且容易出错，以至于真的需要明确的支持。而且，将超级项目的操作映射到子项目的最佳策略也不明确。例如，对超级项目进行分支操作时，是否要在子项目中创建新分支并不确定。 ### 1.2 实现方式及局限性 PRCS使用RCS作为后端存储机制，虽然有助于快速实现一个健壮的原型，但作为长期策略存在一些局限性： | 局限性 | 具体描述 | | ---- | ---- | | 进程启动成本高 | 对每个文件进行版本控制操作时启动新进程成本高 | | 接口复杂 | RCS的调用和锁定约定使高级版本控制系统与RCS的接口不必要地复杂 | | 二进制文件支持不佳 | 对二进制文件的支持不够好 | | 分支机制性能问题 | RCS的分支机制有意外的性能影响，且难以自动或通过用户干预进行优化 | 为避免进程启动成本，可以将RCS实现为一组线程安全的库例程，但这无法解决其接口问题。当前PRCS的实现因管理RCS文件的锁定和解锁、在批量提交前将文件放置或链接到正确路径的代码而变得复杂。此外，RCS的增量机制已过时，新的增量算法性能更优，能处理二进制和文本文件。最后，RCS的分支模型不适合高级工具，它将每个版本强制置于树中，版本在树中的位置极大影响操作性能。 ### 1.3 优化措施 PRCS大量使用时间戳和MD5校验和来最小化文件I/O和RCS调用。尽管MD5优化因关键字替换而复杂，但在仅靠时间戳无法避免比较的情况下，能大大减少I/O。 ### 1.4 未来工作规划 #### 分布式多用户版本控制 完成系统后，发现需要分布式、多用户版本控制，涉及某种客户端/服务器结构。分布式版本控制架构的设计可通过仔细缓存数据并仅传输更改来减少数据传输。目前正在进行客户端/服务器实现的工作。 #### 区分本地和网络提交 计划允许用户区分本地和网络提交。用户在使用全局共享仓库时，因仓库的共享性质，对使用额外的、可能偏离分支的版本进行进度检查点操作感到不适。个人的、可能是本地的修改不应放在全局仓库中，用户被迫使用多个仓库，一个用于本地工作，一个用于共享的团队工作。为解决此问题，计划允许将某些分支标记为本地分支，本地分支不与全局仓库共享，对其他用户不可见。在网络环境中对本地版本的操作将其他本地版本视为透明，追溯其祖先直到找到网络版本。 #### 替代增量算法研究 研究了类似Vdelta算法的替代增量算法以及对RCS的改进，以避免上述分支问题。设计了一个版本控制库，计算新文件与整个版本文件之间的反向增量，避免了RCS式的分支问题，同时保留了“增量在文件版本与其父版本之间计算”的特点。对于有N个版本的仓库，版本I需要应用(N - I)个增量，无论版本集之间的关系如何。这种结构导致一种没有分支性能问题且具有类似存储效率的版本化存储格式。 ### 1.5 结论 PRCS最初是为版本控制问题设计的概念简单的解决方案，充分重用了现有工具（文本编辑器），从用户角度简化操作。它已发展成为一个易于使用、为用户提供简单抽象模型且设计不受特定实现难易影响的系统。观察发现，项目版本的快照、标记版本模型效果良好，比将文件组的版本控制视为对单个文件的分组操作的机制更简单。结