zopyx.versioning 0.1.0

为什么要使用另一个版本控制系统？

在Zope世界中存在的版本化方法是：

基本概念

• 黄金法则1：保持简单，保持小巧
• 可插拔存储API（存储版本化数据）
• 使用json作为要版本化的对象之间的数据交换格式 和versioner以及versioner和后端存储（存储 可能使用不同的序列化格式（例如，zodb的“pickle 基于后端或“json”的典型nosql后端，如mongodb）
• 利用zope组件架构采用任意 存储API的内容对象
• 解决方案不声明存储和还原 内容对象。相反，我们专注于处理元数据和 内容本身。如果对象使用复杂的内部数据模型，则 负责将数据序列化和反序列化为json。
• 保留复杂的功能（可能处理引用、对象关系 等）超出核心版本控制引擎-这可以通过 实现iversionsupport的适配器。

开口点

• 应在存储层还是版本控制层上处理重复数据消除 （我假设存储层是一个可选特性，以便保持 整体复杂度低）< /李>
• 所有可版本化对象都必须提供唯一的id（UIDfor 原型支持内容）。灵巧怎么样？怎么样 基于模式的内容？
• 如何处理“大”内容。例如，基于MongoDB的后端在默认情况下 嵌入文档的4MB限制（通常足够标准内容，但是 不适用于图像等二进制内容）

作者

更改日志

0.1.0（2010-07-09）

• 基于MongoDB的版本存储的初始版本